METHOD FOR DEFINING AND APPLYING A FREQUENCY PLAN

专利摘要:
In an LPWAN communication system comprising a server and a plurality of gateways for performing wireless communications with terminals of said communication system, the server obtains (501) a description of a mobility hierarchy in which types of mobility are hierarchically defined; obtains (502) a description of a mobility tree in which mobility areas are hierarchically defined, in accordance with the mobility hierarchy; obtains (503) field measurements associated with each mobility zone defined in the mobility tree; establishes (504) a frequency plan based on the mobility tree and field measurements; and configures (505) the gateways and terminals according to the established frequency plan.
公开号:FR3052952A1
申请号:FR1655553
申请日:2016-06-15
公开日:2017-12-22
发明作者:Yassir Sennoun；Franck Harnay
申请人:Sagemcom Energy and Telecom SAS；
IPC主号:

专利说明:

où RSSId est une valeur d’index correspondant à la valeur minimum de seuil de niveau de signal reçu RSSI pour laquelle une valeur de probabilité a été exprimée vis-à-vis de la zone de mobilité considérée, RSSIf est une valeur d’index correspondant à la valeur maximum de seuil de niveau de signal reçu RSSI pour laquelle une valeur de probabilité a été exprimée vis-à-vis de la zone de mobilité considérée, TV est la quantité de zones de mobilité considérées pour le calcul de la probabilité moyenne Pm, et Tk(i,j) représente la probabilité associée à la bande de fréquence considérée pour la £-ième zone de mobilité parmi lesdites N zones de mobilités pour un seuil de niveau de signal reçu RSSI représenté par une valeur d’index j.
Selon un mode de réalisation particulier, pour configurer ledit terminal, le serveur effectue les étapes suivantes : informer d’un premier lot de bandes de fréquences attribuées au terminal, via un message de réponse à la requête reçue ; et informer d’un second lot de bandes de fréquences attribuées au terminal, via un ou plusieurs messages complémentaires.
Selon un mode de réalisation particulier, des canaux forment des regroupements de bandes de fréquences consécutives, et le serveur attribue les bandes de fréquences sur une base canal.
Selon un mode de réalisation particulier, le serveur obtient la description de la hiérarchie de mobilité, la description de l’arbre de mobilité, les mesures de terrain, le descriptif de chaque terminal auprès d’un autre serveur externe au système de communication.
Selon un mode de réalisation particulier, le serveur vérifie que le type de mobilité de chaque zone de mobilité de l’arbre de mobilité a un degré hiérarchique inférieur au type de mobilité d’une autre zone de mobilité à laquelle ladite zone de mobilité est directement rattachée dans l’arbre de mobilité.
Selon un mode de réalisation particulier, le descriptif de chaque terminal comporte une information indiquant si le terminal est supposé être fixe, et le serveur effectue les étapes suivantes vis-à-vis du terminal ayant émis la requête reçue : déterminer la liste des bandes de fréquences éligibles audit terminal ; déterminer les bandes de fréquences de cette liste qui ont été attribuées à au moins trois passerelles parmi les passerelles ayant relayé ladite requête ; et attribuer les bandes de fréquences ainsi déterminées audit terminal EP.
Selon un mode de réalisation particulier, pour les fréquences non sélectionnées de ladite liste des bandes de fréquences éligibles, le serveur attend de recevoir d’autres trames en provenance dudit terminal pour déterminer si de nouvelles passerelles ont relayé lesdites autres trames et ainsi déterminer si d’autres bandes de fréquences de ladite liste des bandes de fréquences éligibles ont été attribuées à au moins trois passerelles parmi les passerelles ayant relayé lesdites trames.
Selon un mode de réalisation particulier, dans le cas où la quantité de passerelles réceptrices de trames ascendantes en provenance dudit terminal reste strictement inférieure à trois, le serveur émet une alerte. L’invention concerne également un serveur configuré pour définir et appliquer un plan de fréquences dans un système de communication de type LPWAN comportant, outre ledit serveur, une pluralité de passerelles connectées audit serveur, la pluralité de passerelles utilisant des bandes de fréquences pour effectuer des communications sans-fil avec des terminaux du système de communication. Le serveur est configuré pour : obtenir une description d’une hiérarchie de mobilité dans laquelle des types de mobilité sont hiérarchiquement définis ; obtenir une description d’un arbre de mobilité dans lequel des zones de mobilité sont hiérarchiquement définies, chaque zone de mobilité ayant un type de mobilité en conformité avec la hiérarchie de mobilité ; obtenir des mesures de terrain associées à chaque zone de mobilité définie dans l’arbre de mobilité ; déterminer, à partir des mesures de terrain, pour chaque zone de mobilité, une information de pourcentage de temps pendant lequel les mesures de terrain montrent un niveau de signal reçu RSSI inférieur à tel ou tel seuil de niveau de signal reçu RSSI parmi un ensemble prédéfini de seuils de niveau de signal reçu RSSI. De plus, le serveur est configuré pour parcourir l’arbre de mobilité en itérant les étapes suivantes : sélectionner la zone de mobilité de plus haut degré hiérarchique non encore traitée ; déterminer, pour la zone de mobilité sélectionnée, une probabilité moyenne Pm pour chaque bande de fréquences, à partir desdites informations de pourcentage de temps déterminées pour chaque zone de mobilité qui est une feuille de l’arbre et qui est hiérarchiquement rattachée à la zone de mobilité sélectionnée ; attribuer, pour la zone de mobilité sélectionnée, jusqu’à une quantité P de bandes de fréquences présentant les meilleures probabilités moyennes. De plus, le serveur est configuré pour effectuer les étapes suivantes pour configurer les passerelles vis-à-vis du plan de fréquences : obtenir des descriptifs de gabarits de mobilité dans lesquels des regroupements de zones de mobilité sont effectués et dans lesquels, pour chaque regroupement, une liste de passerelles est associée à chaque regroupement pour indiquer quelles passerelles sont destinées à supporter ledit regroupement ; configurer chaque passerelle en fonction desdits descriptifs de gabarits et des bandes de fréquences attribuées aux zones de mobilité constituant lesdits regroupements. De plus, sur réception de la part d’un terminal d’une requête de connexion au système de communication, le serveur est configuré pour obtenir un descriptif du terminal à partir d’un identifiant de terminal inclus dans ladite requête, le descriptif incluant une liste de types de mobilité auxquels ledit terminal a droit d’accès, et pour itérer les étapes suivantes pour l’intégralité des types de mobilité auxquels ledit terminal a droit d’accès : identifier le type de mobilité de plus haut degré hiérarchique ; identifier quelles zones de mobilité correspondent audit type de mobilité de plus haut degré hiérarchique identifié ; sélectionner une zone de mobilité parmi les zones de mobilité identifiées ; et attribuer audit terminal au moins une bande de fréquences attribuée à la zone de mobilité sélectionnée. Enfin, le serveur est configuré pour configurer ledit terminal en fonction des bandes de fréquences ainsi attribuées audit terminal. L’invention concerne également un programme d’ordinateur, qui peut être stocké sur un support et/ou téléchargé d’un réseau de communication, afin d’être lu par un processeur. Ce programme d’ordinateur comprend des instructions pour implémenter le procédé mentionné ci-dessus, lorsque ledit programme est exécuté par le processeur. L’invention concerne également un medium de stockage d’informations stockant un tel programme d’ordinateur.
Les caractéristiques de l’invention mentionnées ci-dessus, ainsi que d’autres, apparaîtront plus clairement à la lecture de la description suivante d’un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : - la Fig. 1 illustre schématiquement un système de communication dans lequel la présente invention peut être implémentée ; - la Fig. 2 illustre schématiquement un exemple d’architecture matérielle d’un dispositif de communication du système de communication de la Fig. 1 ; - la Fig. 3 illustre schématiquement un exemple de hiérarchie de mobilité destinée à permettre de définir un plan de fréquences adapté au système de communication vis-à-vis de son environnement ; - la Fig. 4 illustre schématiquement un exemple d’arbre de mobilité en application de la hiérarchie de mobilité de la Fig. 3 ; - la Fig. 5 illustre schématiquement un algorithme, implémenté par un serveur du système de communication, de configuration dudit système de communication afin d’appliquer le plan de fréquences adapté au système de communication vis-à-vis de son environnement ; - la Fig. 6 illustre schématiquement un algorithme, implémenté par ledit serveur du système de communication, de création d’un tableau de statistiques de probabilités versus des indications de niveau de signal reçu RSSI (« Received Signal Strength Indicator » en anglais), dans le cadre de la définition du plan de fréquences adapté au système de communication vis-à-vis de son environnement ; - la Fig. 7 illustre schématiquement un algorithme, implémenté par ledit serveur du système de communication, de création d’une table de mobilité, représentative du plan de fréquences défini pour le système de communication ; - la Fig. 8 illustre schématiquement un algorithme, implémenté par ledit serveur du système de communication, de configuration de passerelles du système de communication afin d’appliquer le plan de fréquences défini pour le système de communication ; et - la Fig. 9 illustre schématiquement un algorithme, implémenté par ledit serveur du système de communication, de configuration de terminaux du système de communication afin d’appliquer le plan de fréquences défini pour le système de communication. L’invention est plus particulièrement décrite ci-après dans un contexte d’infrastructure réseau de type LoRaWAN (marque déposée), en utilisant notamment des terminologies que l’on retrouve dans les spécifications LoRaWAN (marque déposée). Les principes et implémentations décrits ci-après s’appliquent cependant, de manière plus générale, à un contexte d’infrastructure réseau de type LPWAN.
La Fig. 1 illustre schématiquement un système de communication dans lequel la présente invention peut être implémentée.
Le système de communication comporte une pluralité de passerelles GW 120, 121, 122, 123. Les passerelles GW 120, 121, 122, 123 disposent de liens de communication respectifs avec un serveur LNS 130 auquel lesdites passerelles GW sont rattachées. Selon un mode de réalisation particulier, chaque passerelle GW 120, 121, 122, 123 intègre une fonction d’accès à l’Internet et le lien de communication entre ladite passerelle résidentielle avec le serveur LNS 130 repose sur le protocole IP (« Internet Protocol » en anglais, tel que défini dans le document normatif RFC 791).
Dans le système de communication, des messages doivent être remontés jusqu’au serveur LNS 130 sous forme de trames depuis chaque dispositif terminal EP («End-Point» en anglais) 110, 111 d’un ensemble de dispositifs terminaux dudit système de communication. Ledit serveur LNS 130 a un rôle de contrôle et de collecte d’informations disponibles auprès des dispositifs terminaux EP 110, 111, et les passerelles GW 120, 121, 122, 123 ont un rôle de relais entre les dispositifs terminaux EP 110, 111 et le serveur LNS 130. Des messages, notamment de commande, peuvent aussi être transmis sous forme de trames depuis le serveur LNS 130 jusqu’aux dispositifs terminaux EP 110, 111 via les passerelles de collecte GW 120, 121, 122, 123. De telles commandes envoyées par le serveur LNS 130 auxdits dispositifs terminaux EP 110, 111 permettent plus particulièrement, dans le cadre de la présente invention, de configurer les dispositifs terminaux EP 110, 111 vis-à-vis d’un plan de fréquences à faire appliquer aux communications sans-fil dans le système de communication.
Pour permettre de remplir ce rôle de relais, chaque passerelle GW 120, 121, 122, 123 dispose d’au moins une interface radio permettant à ladite passerelle de collecte de communiquer avec au moins un dispositif terminal EP 110, 111 en s’appuyant sur un réseau de communication sans-fil, et préférentiellement selon une technologie de communication de type LPWAN. Ladite interface radio est par exemple de type LoRa (marque déposée) permettant ainsi d’implémenter, au sein du système de communication, un protocole de transmission de données de type LoRaWAN (marque déposée). Ladite interface radio est telle qu’un dispositif terminal EP peut être à portée de communication par voie radio d’une pluralité de passerelles GW, selon la position géographique dudit dispositif terminal EP par rapport aux passerelles GW 120, 121, 122, 123 et des conditions de transmission par voie radio dans l’environnement dudit dispositif terminal EP et des passerelles GW 120, 121, 122, 123. C’est le cas par exemple du dispositif terminal EP 110 sur la Fig. 1, qui est à portée de communication par voie radio des passerelles GW 120, 121 et 122. Le dispositif terminal EP 111 sur la Fig. 1 est, quant à lui, à portée de communication par voie radio des passerelles GW 122 et 123.
Le système de communication est préférentiellement connecté, via le serveur LNS 130, à un serveur SOE (« Service Operator Equipment » en anglais) 140, afin de permettre au serveur LNS 130 d’obtenir des informations et descriptifs de la part de l’opérateur de service à la disposition duquel le système de communication a été mis en place. Les communications entre le serveur LNS 130 et le serveur SOE 140 s’appuient sur un protocole de communication adapté pour permettre au serveur LNS 130 d’obtenir lesdites informations et lesdits descriptifs, comme par exemple le protocole TCP (« Transmission Control Protocol » en anglais, tel que défini dans le document normatif RFC 793). En variante de réalisation, le serveur LNS 130 est configuré pour obtenir lesdites informations et lesdits descriptifs via une interface homme-machine implémentée par ledit serveur LNS 130.
La Fig. 2 illustre schématiquement un exemple d’architecture matérielle d’un dispositif de communication du système de communication de la Fig. 1. Chaque dispositif terminal EP 110, 111 et/ou chaque passerelle GW 120, 121, 122, 123 et/ou le serveur LNS 130 et/ou le serveur SOE 140 peuvent être construits sur la base d’une telle architecture matérielle.
Le dispositif de communication comporte, reliés par un bus de communication 210: un processeur ou CPU («Central Processing Unit» en anglais) 201 ; une mémoire vive RAM (« Random Access Memory » en anglais) 202 ; une mémoire morte ROM (« Read Only Memory » en anglais) 203 ; une unité de stockage ou un lecteur de support de stockage, tel qu’un lecteur de cartes SD (« Secure Digital » en anglais) ou un disque dur HDD (« Hard Disk Drive » en anglais) 204 ; une interface de communication I/F 205, et éventuellement une autre interface de communication I/F 206.
Lorsque le dispositif de communication de la Fig. 2 représente un dispositif terminal EP du système de communication, l’interface de communication I/F 205 est configurée pour permettre audit dispositif terminal EP de communiquer avec une ou plusieurs passerelles GW du système de communication.
Lorsque le dispositif de communication de la Fig. 2 représente une passerelle GW du système de communication, l’interface de communication I/F 205 est configurée pour permettre à ladite passerelle GW de communiquer avec des dispositifs terminaux EP du système de communication, et l’autre interface de communication I/F 206 est configurée pour permettre à ladite passerelle GW de communiquer avec le serveur LNS 130.
Lorsque le dispositif de communication de la Fig. 2 représente le serveur LNS 130, l’interface de communication I/F 205 est configurée pour permettre audit serveur LNS 130 de communiquer avec les passerelles GW du système de communication. Dans un mode de réalisation particulier, l’autre interface de communication I/F 206 est configurée pour permettre audit serveur LNS 130 de communiquer avec le serveur SOE 140.
Lorsque le dispositif de communication de la Fig. 2 représente le serveur SOE 140, l’interface de communication I/F 205 est configurée pour permettre audit serveur SOE 140 de communiquer avec le serveur LNS 130.
Le processeur 201 est capable d’exécuter des instructions chargées dans la RAM 202 à partir de la ROM 203, d’une mémoire externe, d’un support de stockage, ou d’un réseau de communication. Lorsque le dispositif de communication est mis sous tension, le processeur 201 est capable de lire de la RAM 202 des instructions et de les exécuter. Ces instructions forment un programme d’ordinateur causant l’implémentation, par le processeur 201, de tout ou partie des algorithmes et étapes décrits ici en relation avec le dispositif de communication en question.
Ainsi, tout ou partie des algorithmes et étapes décrits ici peut être implémenté sous forme logicielle par exécution d’un ensemble d’instructions par une machine programmable, tel qu’un DSP (« Digital Signal Processor » en anglais) ou un microcontrôleur. Tout ou partie des algorithmes et étapes décrits ici peut aussi être implémenté sous forme matérielle par une machine ou un composant dédié, tel qu’un FPGA (« Field-Programmable Gâte Array » en anglais) ou un ASIC (« Application-Specific Integrated Circuit » en anglais).
La Fig. 3 illustre schématiquement un exemple de hiérarchie de mobilité destinée à permettre de définir un plan de fréquences adapté au système de communication vis-à-vis de son environnement.
Le serveur LNS 130 permet à l’opérateur de service de définir une hiérarchie de mobilité consistant en un ensemble hiérarchisé de types de mobilité (MobilityType). Cette définition de la hiérarchie de mobilité est ainsi fournie par le serveur SOE 140 au serveur LNS 130, ou est fournie au serveur LNS 130 par le biais de son interface homme-machine. L’ensemble hiérarchisé de types de mobilité correspond aux différents types de mobilité géographique que les terminaux EP du système de communication sont autorisés à avoir : local, à la dimension d’une ville, régional, national,... ou toute autre hiérarchie de types de couverture géographique. L’ensemble hiérarchisé de types de mobilité est donc un ensemble de types de zones de couverture réseau hiérarchisés selon la taille de leurs couvertures réseau respectives. La convention de nommage des types de mobilité et l’interprétation de la hiérarchie sont à la charge de l’opérateur de service.
La hiérarchie de mobilité est donc un ensemble hiérarchisé de types de mobilité (MobilityType), dont un exemple de réalisation est illustré par la Fig. 3 sous forme d’arbre de nœuds interconnectés. La racine de la hiérarchie est représentée tout en haut de la Fig. 3, et représente le plus haut degré hiérarchique. Chaque nœud de l’arbre comporte au moins deux éléments : un nom de type de mobilité et un pointeur vers le nœud parent dans la hiérarchie. La racine correspond à un type de mobilité génériquement labellisé NO sur la Fig. 3. Par exemple, le type de la racine est nommé « Norme ». La racine n’ayant, par définition, pas de nœud parent, le pointeur associé à la racine est sans signification. Par exemple, ce pointeur est fixé à une valeur prédéfinie (e.g. « 0 ») ou pointe sur la racine elle-même. Deux types de mobilité, génériquement labellisés Nl_l et Nl_2 sur la Fig. 3, sont hiérarchiquement directement attachés à la racine. Par exemple, le type génériquement labellisé Nl_l est nommé «Public» et le type génériquement labellisé Nl_2 est nommé « Corporate ». Les pointeurs des types de mobilité génériquement labellisés Ni l et Nl_2 sur la Fig. 3 pointent sur la racine. Chacun d’eux est ainsi labellisé PNO sur la Fig. 3. Un unique type de mobilité, génériquement labellisé N2_2 sur la Fig. 3, est hiérarchiquement directement attaché au type de mobilité génériquement labellisé Nl_2 sur la Fig. 3. Par exemple, le type de mobilité génériquement labellisé N2 2 sur la Fig. 3 est nommé « Service Postal ». Le pointeur du type de mobilité génériquement labellisé N2_2 sur la Fig. 3 pointe sur le type de mobilité génériquement labellisé Nl_2 sur la Fig. 3, et est ainsi labellisé PN12 sur la Fig. 3. Un unique type de mobilité, génériquement labellisé N2_l sur la Fig. 3, est hiérarchiquement directement attaché au type de mobilité génériquement labellisé Ni l sur la Fig. 3. Par exemple, le type de mobilité génériquement labellisé N2_l sur la Fig. 3 est nommé « National ». Le pointeur du type de mobilité génériquement labellisé N2_l sur la Fig. 3 pointe sur le type de mobilité génériquement labellisé Ni l sur la Fig. 3, et est ainsi labellisé PNl l sur la Fig. 3. Un unique type de mobilité, génériquement labellisé N3_l sur la Fig. 3, est hiérarchiquement directement attaché au type de mobilité génériquement labellisé N2_l sur la Fig. 3. Par exemple, le type de mobilité génériquement labellisé N3_l sur la Fig. 3 est nommé « Agglomération ». Le pointeur du type de mobilité génériquement labellisé N3_l sur la Fig. 3 pointe sur le type de mobilité génériquement labellisé N2_l sur la Fig. 3, et est ainsi labellisé PN21 sur la Fig. 3. Un unique type de mobilité, génériquement labellisé N4_l sur la Fig. 3, est hiérarchiquement directement attaché au type de mobilité génériquement labellisé N3_l sur la Fig. 3. Par exemple, le type de mobilité génériquement labellisé N4_l sur la Fig. 3 est nommé « Ville ». Le pointeur du type de mobilité génériquement labellisé N4_l sur la Fig. 3 pointe sur le type de mobilité génériquement labellisé N3_l sur la Fig. 3, et est ainsi labellisé PN31 sur la Fig. 3. Enfin, un unique type de mobilité, génériquement labellisé N5_l sur la Fig. 3, est hiérarchiquement directement attaché au type de mobilité génériquement labellisé N4_l sur la Fig. 3. Par exemple, le type de mobilité génériquement labellisé N5_l sur la Fig. 3 est nommé « Local ». Le pointeur du type de mobilité génériquement labellisé N5_l sur la Fig. 3 pointe sur le type de mobilité génériquement labellisé N5_l sur la Fig. 3, et est ainsi labellisé PN41 sur la Fig. 3.
Chaque nœud de l’arbre peut comporter un ou plusieurs éléments supplémentaires, comme par exemple un pointeur vers chacun de ses éventuels nœuds enfants dans la hiérarchie de mobilité.
Dans le cas où le serveur LNS 130 doit gérer plusieurs hiérarchies, un tel arbre est fourni au serveur LNS 130 pour chacune desdites hiérarchies et peuvent ainsi avoir des structures différentes, des conventions de nommages différentes, ainsi que des interprétations différentes. Un identifiant de hiérarchie est alors utilisé pour distinguer, les unes par rapport aux autres, les hiérarchies ainsi définies.
La Fig. 4 illustre schématiquement un exemple d’arbre de mobilité en application de la hiérarchie de mobilité telle que précédemment décrite en relation avec la Fig. 3.
Un arbre de mobilité est une instance d’une hiérarchie de mobilité. Cet arbre correspond à une description de couverture géographique des communications sans-fil du système de communication pour un service donné, dans lequel chaque nœud de l’arbre est une instance d’un type de mobilité défini dans ladite hiérarchie de mobilité et dans lequel chaque nœud de l’arbre est associé à une zone de mobilité (MobilityArea). Chaque zone de mobilité est associée à un type de mobilité (MobilityType) avec un degré hiérarchique inférieur à celui associé à son nœud parent, ou zone de mobilité parente. Chaque nœud de l’arbre comporte au moins quatre éléments : un nom MA de zone de mobilité, le type de mobilité de ladite zone de mobilité, un pointeur PTR vers la zone de mobilité parente, et au moins une bande de fréquences F associée à ladite zone de mobilité. La ou les bandes de fréquences F associées à ladite zone de mobilité sont déterminées comme décrit ci-après en relation avec les Figs. 6 à 8.
Un exemple d’arbre de mobilité est représenté sur la Fig. 4, en s’appuyant sur l’exemple de hiérarchie de mobilité représenté sur la Fig. 3. L’arbre de mobilité comporte alors une racine 401 qui est une instance de type de mobilité « Norme ». Par exemple, la racine 401 représente une zone de mobilité MA dénommée « LoRa ». L’arbre de mobilité comporte aussi deux nœuds 411 et 441 directement attachés à la racine 401. Le nœud 411 est une instance de type de mobilité « Public », et le nœud 441 est une instance de type de mobilité « Corporate». Par exemple, le nœud 411 représente une zone de mobilité MA dénommée « Public », et le nœud 441 représente une zone de mobilité MA dénommée «Corporate». L’arbre de mobilité comporte aussi deux nœuds 421 et 431 directement attachés au nœud 411. Les nœuds 421 et 431 sont des instances de type de mobilité «National». Par exemple, le nœud 421 représente une zone de mobilité MA dénommée «Tunisie», et le nœud 431 représente une zone de mobilité MA dénommée « France ». Un unique nœud 422 est directement attaché au nœud 421. Le nœud 422 est une instance de type de mobilité « Ville ». Par exemple, le nœud 422 représente une zone de mobilité MA dénommée « Tunis ». On notera donc que chaque zone de mobilité est associée à un type de mobilité (MobilityType) de degré hiérarchique inférieur à celui associé à sa zone de mobilité parente dans l’arbre de mobilité, sans qu’il ne soit nécessaire que ladite zone de mobilité soit associée à un type de mobilité (MobilityType) de degré hiérarchique immédiatement inférieur à celui associé à sa zone de mobilité parente dans la hiérarchie de mobilité considérée. En d’autres termes, des sauts de degré hiérarchique peuvent être effectués pour définir l’arbre de mobilité, par rapport à la définition de la hiérarchie de mobilité dont l’arbre de mobilité est une instance. Un unique nœud 432 est directement attaché au nœud 431. Le nœud 432 est une instance de type de mobilité « Agglomération ». Par exemple, le nœud 432 représente une zone de mobilité MA dénommée « Agglomération Parisienne ». Un unique nœud 433 est directement attaché au nœud 432. Le nœud 433 est une instance de type de mobilité « Ville ». Par exemple, le nœud 433 représente une zone de mobilité MA dénommée « Rueil ». Un unique nœud 434 est directement attaché au nœud 433. Le nœud 434 est une instance de type de mobilité « Local ». Par exemple, le nœud 434 représente une zone de mobilité MA dénommée « Sagemcom ». Enfin, un unique nœud 442 est directement attaché au nœud 441. Le nœud 442 est une instance de type de mobilité « Service Postal ». Par exemple, le nœud 442 représente une zone de mobilité MA dénommée « Garages Automobiles ».
Chaque nœud de l’arbre peut comporter un ou plusieurs éléments supplémentaires SI, comme par exemple un pointeur vers chacun de ses éventuels nœuds enfants.
Dans le cas où le serveur LNS 130 doit gérer plusieurs hiérarchies, un tel arbre est fourni au serveur LNS 130 en association avec un identifiant de hiérarchie affecté à la hiérarchie de mobilité à laquelle ledit arbre de mobilité se réfère. Plusieurs arbres de mobilité peuvent être définis comme instances distinctes d’une même hiérarchie de mobilité. Un identifiant d’arbre de mobilité est alors utilisé pour distinguer, les uns par rapport aux autres, les arbres de mobilité ainsi définis.
La Fig. 5 illustre schématiquement un algorithme, implémenté par le serveur LNS 130, de configuration du système de communication afin d’appliquer un plan de fréquences adapté au système de communication vis-à-vis de son environnement.
Dans une étape 501, le serveur LNS 130 obtient une description de hiérarchie de mobilité, telle que présentée ci-dessus en relation avec la Fig. 3.
Dans une étape 502, le serveur LNS 130 obtient une description d’un arbre de mobilité, telle que présentée ci-dessus en relation avec la Fig. 4. Préférentiellement, le serveur LNS 130 vérifie la conformité de l’arbre de mobilité vis-à-vis de la hiérarchie de mobilité.
Dans une étape 503, le serveur LNS 130 obtient des mesures de terrain associées à chaque zone de mobilité définie dans l’arbre de mobilité. Cet aspect est détaillé par la suite en relation avec la Fig. 6.
Dans une étape 504, le serveur LNS 130 établit un plan de fréquence à appliquer au sein du système de communication, à partir des mesures de terrain et de l’arbre de mobilité, afin d’améliorer les performances de communication du système de communication vis-à-vis de son environnement. Cet aspect est détaillé par la suite en relation avec la Fig. 7.
Dans une étape 505, le serveur LNS 130 instruit les passerelles GW et les terminaux EP du système de communication d’appliquer le plan de fréquences défini à l’étape 504. Cet aspect est détaillé par la suite en relation avec les Figs. 8 et 9.
La Fig. 6 illustre schématiquement un algorithme, implémenté par le serveur LNS 130, de création d’un tableau de statistiques de probabilités versus des indications de niveau de signal reçu RSSI, dans le cadre de la définition du plan de fréquences adapté au système de communication vis-à-vis de son environnement.
Dans une étape 601, le serveur LNS 130 obtient des mesures de terrain, pour chaque zone de mobilité (MobilityArea) qui est une feuille (point de terminaison de l’arbre par rapport à la racine de l’arbre) dans l’arbre de mobilité obtenu par le serveur LNS 130 à l’étape 501. Les mesures de terrain sont fournies au serveur LNS 130 par le serveur SOE 140 ou par saisie via son interface homme-machine.
Le serveur LNS 130 manipule les mesures de terrain obtenues, de sorte à obtenir, par bande de fréquence ou par canal utilisable pour les communications sans-fil entre les passerelles GW et les terminaux EP, une information de pourcentage de temps pendant lequel les mesures de terrain montrent un niveau de signal reçu inférieur à tel ou tel seuil de niveau de signal reçu RSSI parmi un ensemble prédéfini de seuils de niveau de signal reçu RSSI. Cet aspect est détaillé ci-après en regard du reste de l’algorithme de la Fig. 6.
Les mesures de terrain sont acquises de la manière suivante. L’objectif est de connaître, avec la meilleure précision possible, le bruit présent dans les différentes bandes de fréquences dans lesquelles le système de communication est autorisé à effectuer des communications, afin de pouvoir déterminer un plan de fréquences adapté au système de communication vis-à-vis de son environnement.
Le principe de la mesure consiste, pour chaque zone de mobilité concernée, à connecter un récepteur radio de type analyseur de spectre sur une antenne d’un point haut de ladite zone de mobilité et à enregistrer au fil du temps des échantillons de bruit dans les différentes bandes de fréquences. Par exemple, le système de communication est autorisé à effectuer des communications dans des bandes de fréquences de 25 kHz entre 863 MHz à 870 MHz. Le récepteur radio enregistre des variations du niveau reçu RSSI pendant une durée prédéfinie par bande de fréquences, et procède ainsi successivement pour l’ensemble des bandes de fréquences dans lesquelles le système de communication est autorisé à effectuer des communications. Cette procédure peut être itérée sur plusieurs cycles, les mesures acquises étant alors combinées selon une règle prédéfinie (addition, moyenne, max, min,...) à celles précédemment acquises. Plus la quantité de cycles effectués est grande, plus la précision sur les bruits statistiquement présents dans les bandes de fréquence considérées est grande. Les mesures peuvent ensuite être regroupées par canal de communication, si de tels canaux de communication regroupant plusieurs bandes de fréquences consécutives sont définis pour effectuer les communications sans-fil du système de communication. Par exemple, les mesures effectuées sont regroupées par canal de communication de 125 kHz de largeur, regroupant ainsi chacun cinq bandes de fréquences consécutives de 25 kHz. Ce regroupement peut aussi être effectué par le serveur LNS 130, comme décrit ci-après en relation avec une étape 602.
Ainsi, les mesures effectuées peuvent être présentées sous la forme d’un tableau de mesures ayant en ordonnées les bandes de fréquences ou canaux considérés et en abscisses des valeurs prédéfinies (seuils) de niveau reçu RSSI. Chaque cellule du tableau comporte alors, pour la bande de fréquence ou canal correspondant à ladite cellule, une information de temps pendant lequel les mesures effectuées montrent un niveau de signal reçu RSSI inférieur ou égal à la valeur prédéfinie (seuil) de niveau reçu RSSI correspondant à ladite cellule. A chaque ligne du tableau est associée une information de temps T pendant lequel les mesures ont été effectuées pour la bande de fréquences ou le canal correspondant à ladite ligne.
Dans l’étape 602, pour effectuer au besoin des regroupements de mesures par canal à partir de mesures obtenues par bande de fréquences (chaque canal étant un regroupement prédéfini de plusieurs bandes de fréquences consécutives), le serveur LNS 130 ajoute entre elles les valeurs contenues dans les cellules concernées du tableau de mesures de terrain. A chaque canal est alors associée la somme des informations de temps T qui étaient précédemment associées aux bandes de fréquences constituant ledit canal. A partir des mesures effectuées, il est possible de déterminer par bande de fréquences ou par canal, le pourcentage du temps pendant lequel il n’y a statistiquement pas de bruit supérieur à une valeur donnée (seuil) de signal reçu RSSI. Pour cela, dans une étape 603, le serveur LNS 130 détermine, pour chaque bande de fréquence ou canal en question, le temps des mesures de terrain qui ont donné un niveau de signal reçu RSSI inférieur à la valeur prédéfinie (seuil) de signal reçu RSSI considérée, et ce, vis-à-vis de chaque valeur prédéfinie (seuil) de signal reçu RSSI. Le serveur LNS 130 divise ensuite ce temps par la quantité d’unités de temps pendant lesquelles les mesures ont été effectuées pour la bande de fréquence ou le canal en question, ce qui donne, par valeur de seuil RSSI, le pourcentage de temps recherché.
Dans une étape 604, le serveur LNS 130 crée, ou met à jour, un tableau de statistiques de probabilités versus niveau de signal reçu RSSI. Ce tableau de statistiques contient alors en ordonnées les bandes de fréquences ou canaux considérés et en abscisses les valeurs prédéfinies (seuils) de niveau reçu RSSI. Chaque cellule du tableau comporte alors, pour la bande de fréquence ou canal correspondant à ladite cellule, l’information de pourcentage de temps pendant lequel les mesures de terrain ont donné un niveau de signal reçu RSSI inférieur ou égal à la valeur prédéfinie (seuil) de niveau de signal reçu RSSI correspondant à ladite cellule. Le tableau de statistiques ainsi créé est ensuite utilisé par le serveur LNS 130, comme détaillé ci-dessous en relation avec la Fig. 7. Dans un mode de réalisation en variante, le serveur LNS 130 reçoit du serveur SOE 140, ou via son interface homme-machine, directement le tableau de statistiques de probabilités versus niveau de signal reçu RSSI.
La Fig. 7 illustre schématiquement un algorithme, implémenté par le serveur LNS 130, de création d’une table de mobilité représentative du plan de fréquences défini pour le système de communication.
Dans une étape 701, le serveur LNS 130 sélectionne la zone de mobilité de plus haut degré hiérarchique non encore traitée dans le cadre de l’exécution courante de l’algorithme de la Fig. 7. Lorsqu’il existe plusieurs zones de mobilité de même degré hiérarchique pouvant être sélectionnées par le serveur LNS 130 dans l’étape 701, le serveur LNS 130 applique une règle prédéfinie pour sélectionner une zone de mobilité parmi les zones de mobilité de même degré hiérarchique pouvant être sélectionnées par le serveur LNS 130 dans l’étape 701. A la première itération en séquence de l’étape 701 dans le cadre de l’exécution courante de l’algorithme de la Fig. 7, le serveur LNS 130 sélectionne la zone de mobilité racine de l’arbre de mobilité.
Dans une étape 702, le serveur LNS 130 détermine, pour la zone de mobilité sélectionnée à l’étape 701, une probabilité moyenne Pm pour chaque bande de fréquences ou canal, à partir du tableau de statistiques (de probabilités versus niveau de signal reçu RSSI) obtenu vis-à-vis de chaque zone de mobilité qui se trouve être une feuille de l’arbre de mobilité et qui est hiérarchiquement (indirectement ou directement) rattachée à la zone de mobilité sélectionnée à l’étape 701. Cette probabilité moyenne Pm est représentative de la probabilité qu’il n’y ait pas de bruit menant à une valeur de RSSI donnée sur la bande de fréquences ou le canal en question.
La probabilité moyenne Pm susmentionnée est calculée de la façon suivante :
où RSSld est une valeur d’index correspondant à la valeur minimum de seuil RSSI pour laquelle une valeur de probabilité a été exprimée dans le tableau de probabilité considéré, RSSIf est une valeur d’index correspondant à la valeur maximum de seuil RSSI pour laquelle une valeur de probabilité a été exprimée dans le tableau de probabilité considéré, N est la quantité de tableaux de statistiques de probabilités considérés pour le calcul de la probabilité moyenne
représente la probabilité associée à la bande de fréquence considérée ou au canal considéré dans le k-ième tableau de probabilité (parmi lesdits tableaux considérés) pour un seuil RSSI représenté par une valeur d’index j.
Dans une étape 703, le serveur LNS 130 sélectionne jusqu’à une quantité prédéfinie P (P > 1) de bandes de fréquences ou canaux parmi les bandes de fréquences ou canaux utilisables par le système de communication pour effectuer les communications sans-fil. Les bandes de fréquences ou canaux sélectionnés par le serveur LNS 130 sont les bandes de fréquences ou canaux présentant les meilleures probabilités moyennes (valeurs les plus élevées) telles que calculées à l’étape 702, pour peu que les bandes de fréquences ou canaux en question n’aient pas déjà été attribués à la racine ou à une zone de mobilité qui est un intermédiaire dans l’arbre de mobilité entre la racine et la zone de mobilité sélectionnée à l’étape 701. Si moins de P bandes de fréquences ou canaux subsistent après avoir retiré les bandes de fréquences ou canaux attribués à la racine ou à une zone de mobilité qui est un intermédiaire dans l’arbre de mobilité entre la racine et la zone de mobilité sélectionnée à l’étape 701, alors le serveur LNS 130 sélectionne ces bandes de fréquences ou canaux qui subsistent. Si toutes les fréquences ont été sélectionnées et qu’il reste encore des zones de mobilités à traiter, alors le serveur LNS 130 n’alloue pas de lui-même de fréquences à ces zones de mobilité. Il s’agit d’un cas de mauvais dimensionnement du système de communication par l’opérateur de service. Par conséquent, le serveur LNS 130 envoie une alarme au serveur SOE 140 afin que l’opérateur de service puisse définir en retour une politique d’allocation de fréquences en conséquence, comme par exemple forcer l’attribution des P bandes de fréquences ou canaux ayant les meilleures probabilités moyennes ou annuler la mise en place, en cours, du plan de fréquences. Si au moins P bandes de fréquences ou canaux subsistent après avoir retiré les bandes de fréquences ou canaux attribués à la racine ou à une zone de mobilité qui est un intermédiaire dans l’arbre de mobilité entre la racine et la zone de mobilité sélectionnée à l’étape 701, le serveur LNS 130 sélectionne les P bandes de fréquences ou canaux présentant les meilleures probabilités moyennes telles que calculées à l’étape 702. Les bandes de fréquences ou canaux ainsi sélectionnés par le serveur LNS 130 sont alors attribués à la zone de mobilité sélectionnée à l’étape 701.
La quantité P peut être un paramètre par défaut du serveur LNS 130 ; la quantité P peut en variante être un paramètre fourni par le serveur SOE 140 au serveur LNS 130. A noter que le paramètre P est potentiellement différent d’une zone de mobilité à une autre.
Dans une étape 704, le serveur LNS 130 vérifie si au moins une autre zone de mobilité de l’arbre de mobilité doit être considérée. Le serveur LNS 130 est supposé parcourir l’arbre de la racine de l’arbre vers chaque feuille de l’arbre, jusqu’à ce que l’arbre soit intégralement parcouru. Si au moins une moins une autre zone de mobilité doit être considérée, l’étape 701 est réitérée ; sinon, une étape 705 est effectuée.
Dans l’étape 705, le serveur LNS 130 crée, ou met à jour, une table de mobilité associée à l’arbre de mobilité en question. La table de mobilité fournit, pour chaque zone de mobilité de l’arbre de mobilité, une ou plusieurs bandes de fréquences ou canaux qui ont ainsi été attribués à ladite zone de mobilité. La table de mobilité peut contenir des informations complémentaires, comme par exemple un rappel du type de mobilité caractérisant la zone de mobilité en question, un rappel de la zone de mobilité parente dans l’arbre de mobilité,...
La Fig. 8 illustre schématiquement un algorithme, implémenté par le serveur LNS 130, de configuration des passerelles GW afin d’appliquer le plan de fréquences tel que défini par exécution de l’algorithme de la Fig. 7.
Dans une étape 801, le serveur LNS 130 obtient des descriptifs de gabarits de mobilité qui correspondent respectivement à des ensembles de zones de mobilité. En effet, afin de couvrir le plus de zones de mobilité possibles, chaque passerelle GW supporte préférentiellement plusieurs zones de mobilité, ce qui se traduit par le fait de gérer des bandes de fréquences ou canaux attribués à plusieurs zones de mobilité. Pour y parvenir, le serveur LNS 130 obtient ces gabarits de mobilité auprès du serveur SOE 140 ou par saisie via son interface homme-machine.
Pour avoir de la cohérence au niveau de la couverture radio, il faut que toutes les bandes de fréquences (ou canaux) ou une même partie de ces bandes de fréquences (ou canaux) attribués à chaque zone de mobilité soient configurées dans toutes les passerelles GW auxquelles la zone de mobilité correspond. En effet, les terminaux EP supposés être actifs dans une même zone de mobilité doivent être configurés de sorte à communiquer via des bandes de fréquences ou canaux attribués à cette zone de mobilité. Si un terminal EP est configuré avec une bande de fréquences ou un canal qui n’est pas configuré dans une passerelle GW environnante susceptible de recevoir les trames ascendantes (« uplink frames » en anglais) émises par ledit terminal, alors ces trames ascendantes ne sont pas reçues par cette passerelle GW. Par conséquent, une mauvaise configuration vis-à-vis du plan de fréquences augmente inutilement le taux de pertes de trames (« Frame Error Rate » en anglais).
Il est en outre envisageable de découper le plan de fréquences d’une passerelle GW en plusieurs hiérarchies. Par exemple, une quantité de canaux pourrait être affectée à une première hiérarchie de mobilité et une quantité d’autres canaux pourrait être affectée à une seconde hiérarchie de mobilité. Il faut garder à l’esprit qu’une mauvaise configuration pourrait engendrer des doublons de bandes de fréquences, ce qui perturberait la mise en place de ces hiérarchies en parallèle.
Chaque descriptif de gabarit comporte les informations suivantes : un identifiant de gabarit, une liste des zones de mobilité contenues dans la zone de couverture radio associée au gabarit, et une liste des passerelles GW qui doivent permettre de réaliser ladite zone de couverture radio. Lorsque le système de communication supporte plusieurs hiérarchies de mobilité en parallèle, chaque gabarit comporte en outre un identifiant de la hiérarchie de mobilité à laquelle ledit gabarit réfère.
Dans une étape 802, le serveur LNS 130 détermine, à partir de la table de mobilité obtenue par exécution de l’algorithme de la Fig. 7 et des descriptifs de gabarits obtenus à l’étape 801, la liste des bandes de fréquences ou canaux attribués à chaque gabarit. Cette liste correspond à l’agrégation des bandes de fréquences ou canaux attribués aux zones de mobilité constituant le gabarit en question. Le serveur LNS 130 peut mettre à jour les descriptifs de gabarits avec la liste des bandes de fréquences respectivement attribuées auxdits gabarits.
Dans une étape 803, le serveur LNS 130 crée une table d’allocation fréquentielle GWT-F pour chaque passerelle GW, à partir des descriptifs des gabarits. Chaque descriptif de gabarit donne la liste de passerelles GW concernées par le gabarit en question, et les listes des bandes de fréquences ou canaux attribués à chaque gabarit permettent alors au serveur LNS 130 de définir quelles bandes de fréquences ou canaux doivent être supportés par chaque passerelle GW. Chaque table d’allocation fréquentielle GWT-F indique alors une liste des bandes de fréquences ou canaux en association avec un identifiant de gabarit d’où provient ladite liste de bandes de fréquences ou canaux, et ce, pour chaque gabarit concerné par la passerelle GW à laquelle réfère ladite table d’allocation fréquentielle GWT-F. Lorsque le système de communication supporte plusieurs hiérarchies de mobilité en parallèle, chaque table d’allocation fréquentielle GWT-F peut en outre inclure l’identifiant de la hiérarchie de mobilité à laquelle chaque gabarit réfère.
Dans une étape 803, le serveur LNS 130 configure chaque passerelle GW de sorte à ce que ladite passerelle GW utilise, pour communiquer par radio avec des terminaux EP, les bandes de fréquences ou canaux qui lui ont été attribués selon la table d’allocation fréquentielle GWT-F associée à ladite passerelle GW. L’étape 803 est par exemple effectuée par envoi d’un message du serveur LNS 130 vers chacune des passerelles GW, en utilisant un format JSON (« JavaScript Object Notation » en anglais). Chaque passerelle GW se configure alors en conséquence.
La Fig. 9 illustre schématiquement un algorithme, implémenté par le serveur LNS 130, de configuration des terminaux EP afin d’appliquer le plan de fréquences tel que défini par exécution de l’algorithme de la Fig. 7.
Dans une étape 901, le serveur LNS 130 reçoit une requête JoinReq de connexion au système de communication de la part d’un terminal EP. Cette requête JoionReq est relayée jusqu’au serveur LNS 130 par au moins une passerelle GW l’ayant reçue directement de la part du terminal EP. Pour émettre cette requête JoinReq, le terminal EP utilise une bande de fréquences qui est obligatoirement supportée par tout terminal EP et par toute passerelle GW lorsque ce terminal EP ou cette passerelle GW est destiné à être utilisé au sein du système de communication. Par exemple, selon la technologie LoRaWAN, tout terminal EP et toute passerelle GW doivent supporter trois bandes de fréquences par défaut. L’attribution de bandes de fréquences ou canaux à laquelle il est fait référence dans les Figs. 6 à 8 concerne les bandes de fréquences ou canaux autres que ceux supportés par défaut par tout terminal EP et par toute passerelle GW.
Dans une étape 902, le serveur LNS 130 obtient un descriptif du terminal EP en provenance duquel le serveur LNS 130 a reçu la requête JoinReq à l’étape 901. La requête JoinReq reçue à l’étape 901 contient un identifiant du terminal EP. Dans un premier mode de réalisation, le serveur SOE 140 a fourni au préalable au serveur LNS 130 un descriptif de chaque terminal EP susceptible de se connecter au système de communication. Dans un second mode de réalisation, le serveur LNS 130 obtient l’identifiant du terminal EP à partir de la requête JoinReq reçue à l’étape 901, et envoie au serveur SOE 140 un message contenant ledit identifiant afin de recevoir en réponse le descriptif du terminal EP en question. Le descriptif de chaque terminal EP contient une liste de types de mobilité (MobilityType) et une quantité de bandes de fréquences ou canaux à attribuer au terminal EP en question par type de mobilité listé. Le descriptif peut être complété avec des informations supplémentaires, comme par exemple une quantité de répétitions NbRep que le terminal EP est supposé effectuer pour chaque transmission de trame, un débit ascendant maximum, un débit ascendant minimum,... Lorsque le système de communication supporte plusieurs hiérarchies de mobilité en parallèle, le descriptif contient en outre l’identifiant de chaque hiérarchie de mobilité vis-à-vis de laquelle ledit terminal EP doit être configuré. Le descriptif du terminal EP tel que fourni par le serveur SOE 140 dépend par exemple d’un abonnement effectivement souscrit par un utilisateur dudit terminal EP auprès de l’opérateur de service.
Dans une étape 903, le serveur LNS 130 identifie, à partir du descriptif du terminal EP obtenu à l’étape 902 (avec la liste de types de mobilité), quel est le type de mobilité de plus haut degré hiérarchique à laquelle ledit terminal EP a droit d’accès. Lorsqu’il existe plusieurs types de mobilité de même degré hiérarchique pouvant être identifiés par le serveur LNS 130 dans l’étape 903, le serveur LNS 130 applique une règle prédéfinie pour sélectionner un type de mobilité parmi ceux de même degré hiérarchique pouvant être identifiés par le serveur LNS 130 dans l’étape 903.
Dans une étape 904, le serveur LNS 130 identifie, à partir du type de mobilité identifié à l’étape 902 et à partir de l’arbre de mobilité (instances de types de mobilités), quelles sont les zones de mobilité de plus haut degré hiérarchique à laquelle ledit terminal EP a droit d’accès.
Dans une étape 905, le serveur LNS 130 vérifie si au moins une zone de mobilité a été identifiée à l’étape 904. Si tel est le cas, une étape 906 est effectuée ; sinon, une étape 909 est effectuée.
Dans l’étape 906, le serveur LNS 130 sélectionne une zone de mobilité parmi les zones identifiées à l’étape 904. Ainsi, lorsqu’il existe plusieurs zones de mobilité de même degré hiérarchique pouvant être identifiées par le serveur LNS 130 dans l’étape 904, le serveur LNS 130 applique une règle prédéfinie pour sélectionner une zone de mobilité parmi celles de même degré hiérarchique identifiées par le serveur LNS 130 dans l’étape 904. Par exemple, le serveur LNS 130 sélectionne la zone de mobilité qui est incluse dans un descriptif de gabarit qui présente la plus grande quantité de passerelles GW listées. Selon une autre approche, le serveur LNS 130 sélectionne la zone de mobilité supportée par la plus grande quantité de passerelles GW. Le serveur LNS 130 peut alors en faire la requête auprès du serveur SOE 140 en lui fournissant une liste des zones identifiées à l’étape 904. Selon encore une autre approche, le serveur LNS 130 obtient, de la part de chaque passerelle GW ayant reçu et relayé la requête à laquelle il est fait référence à l’étape 901, une information de niveau de signal reçu RSSI mesuré à la réception de ladite requête par ladite passerelle GW. Le serveur LNS 130 détermine alors une moyenne des niveaux de signal reçu RSSI mesurés à la réception de ladite requête par les passerelles GW de chaque zone de mobilité concernée, et le serveur LNS 130 sélectionne la zone de mobilité présentant la moyenne la plus élevée de niveau de signal reçu RSSI mesuré à la réception de ladite requête.
Dans une étape 907, le serveur LNS 130 sélectionne, selon une règle prédéfinie, au moins une bande de fréquences ou au moins un canal attribué à la zone de mobilité sélectionnée à l’étape 906, grâce à la table de mobilité. Par exemple, le serveur LNS 130 sélectionne aléatoirement au moins une bande de fréquences ou au moins un canal attribué à la zone de mobilité sélectionnée à l’étape 906. Chaque terminal EP ne pouvant supporter qu’une quantité maximum prédéfinie de bandes de fréquences ou de canaux, le serveur LNS 130 sélectionne ainsi une quantité de bandes de fréquences ou de canaux dans l’étape 907, de sorte que, au total, une quantité de bandes de fréquences ou de canaux sélectionnés pour le terminal EP reste inférieure ou égale à la quantité maximum prédéfinie de bandes de fréquences ou de canaux que peut supporter le terminal EP. Par exemple, cette quantité maximum prédéfinie de bandes de fréquences ou de canaux que peut supporter le terminal EP est fixée à treize.
Dans une étape 908, le serveur LNS 130 vérifie si la quantité maximum prédéfinie de bandes de fréquences ou de canaux que peut supporter le terminal EP est atteinte. Si tel est le cas, une étape 911 est effectuée ; sinon, l’étape 909 est effectuée.
Dans l’étape 909, le serveur LNS 130 vérifie si au moins un type de zone de mobilité reste à traiter. Si tel est le cas, une étape 910 est effectuée ; sinon, l’étape 911 est effectuée.
Dans l’étape 910, le serveur LNS 130 identifie quel est le type de mobilité de plus haut degré hiérarchique à laquelle ledit terminal EP a droit d’accès, en excluant chaque type de mobilité précédemment traité dans le cadre de l’exécution de l’algorithme de la Fig. 9 (itérations précédentes des étapes 903 et 910 dans le cadre de l’exécution courante de l’algorithme de la Fig. 9). Ensuite, l’étape 904 est réitérée.
Dans l’étape 911, le serveur LNS 130 configure le terminal EP de sorte à ce que ledit terminal EP utilise, pour communiquer par radio au sein du système de communication, les bandes de fréquences ou canaux qui ont été sélectionnés lors des précédentes itérations de l’étape 907 (dans le cadre de l’exécution courante de l’algorithme de la Fig. 9).
Dans un mode de réalisation particulier, conforme aux formats de messages utilisés dans la technologie LoRaWAN, le serveur LNS 130 configure le terminal EP de la façon suivante. Le serveur LNS 130 informe le terminal EP d’un premier lot de bandes de fréquences ou canaux à utiliser, dans un message JoinAccept en réponse à la requête JoinReq reçue à l’étape 901. Le serveur LNS 130 utilise une passerelle GW comme relais du message JoinAccept. Préférentiellement, conformément aux formats de messages utilisés dans la technologie LoRaWAN, jusqu’à cinq bandes de fréquences ou canaux sont ainsi indiqués dans le message JoinAccept. Le serveur LNS 130 informe ensuite le terminal EP d’un second lot de bandes de fréquences ou canaux à utiliser, dans un ou plusieurs messages complémentaires NewChannelReq. Préférentiellement, conformément aux formats de messages utilisés dans la technologie LoRaWAN, une seule bande de fréquences ou un seul canal est ainsi indiqué dans chaque message complémentaire NewChannelReq. Le serveur LNS 130 procède ainsi jusqu’à ce que ledit terminal EP soit informé de l’intégralité des bandes de fréquences ou canaux qui ont été sélectionnés pour ledit terminal EP lors des précédentes itérations de l’étape 907 (dans le cadre de l’exécution courante de l’algorithme de la Fig. 9). Le terminal EP se configure alors en conséquence.
Dans un autre mode de réalisation particulier, le descriptif du terminal EP obtenu à l’étape 902 comporte une information, fournie par le serveur SOE 140, indiquant si le terminal EP est supposé être fixe (e.g. le terminal EP est un capteur fixe dans un service de domotique). Afin de permettre de localiser effectivement un terminal EP fixe, le serveur LNS 130 doit configurer ledit terminal EP avec des bandes de fréquences ou des canaux supportés par au moins trois passerelles GW susceptibles de recevoir les trames ascendantes transmises par ledit terminal EP. Comme expliqué précédemment, le serveur LNS 130 détermine la liste des bandes de fréquences ou des canaux éligibles audit terminal EP. En fonction des passerelles GW qui ont relayé la requête JoinReq pour permettre au serveur LNS 130 de recevoir ladite requête JoinReq à l’étape 901, le serveur LNS 130 détermine les bandes de fréquences ou canaux de cette liste qui ont été attribués à au moins trois passerelles GW parmi les passerelles GW ayant relayé ladite requête JoinReq. Le serveur LNS 130 attribue ces bandes de fréquences ou canaux audit terminal EP. Pour les fréquences non sélectionnées, le serveur LNS 130 attend préférentiellement de recevoir plus de trames ascendantes en provenance dudit terminal EP pour déterminer si de nouvelles passerelles GW ont reçu, et donc relayé, lesdites trames ascendantes. Le serveur LNS 130 détermine si d’autres bandes de fréquences ou canaux de la liste des bandes de fréquences ou des canaux éligibles audit terminal EP ont été attribués à au moins trois passerelles GW parmi les passerelles GW ayant relayé lesdites trames ascendantes. Dans le cas où la quantité de passerelles GW réceptrices de trames ascendantes en provenance dudit terminal EP est toujours strictement inférieure à trois, la localisation effective dudit terminal EP n’est pas possible. L’affectation de bandes de fréquences ou de canaux audit terminal EP s’effectue alors, comme précédemment décrit, sans tenir compte du besoin de localisation du terminal EP. Le serveur LNS 130 émet alors une alerte auprès du serveur SOE 140 afin d’informer ledit serveur SOE 140, et donc l’opérateur de service, que la localisation n’est pas possible pour ledit terminal EP.
The present invention relates to a definition and application of a frequency plan in an LPWAN type communication system. The Internet of Things ("Internet of Things") is emerging. The Internet of Things represents the extension of the Internet to things and places in the physical world. While the Internet does not usually extend beyond the electronic world, the Internet of Things represents the exchange of information and data from real-world devices to the Internet, such as collection of records of electricity consumption or water consumption, or collection of sensor measurements in a general manner. The Internet of Things is considered the third evolution of the Internet, called Web 3.0. The Internet of Things has a universal character to designate objects connected to various uses, for example in the industrial field, agro-food, e-health or home automation.
In the context of the Internet of Things, gateways on geographically high points are deployed on behalf of a service operator to create a network infrastructure to enable communicating objects to communicate. Except for maintenance operations, these gateways are typically fixed and permanent. For example, the SigFox (registered trademark) or ThingPark (registered trademark) networks can be mentioned on this model. These gateways communicate with communicating objects through LPWAN medium or long-range wireless communication systems, such as LoRaWAN (Long Range Wide-Area Network) technology, also known as diminutive "LoRa" (trademark, "Long Range" in English) of the name of the alliance promoting long-range wide-area network technologies LoRaWAN (registered trademark). These gateways serve as a relay between the communicating objects and a server (core network), called LNS (LoRa NetServer in English, according to LoRaWAN technology terminology) configured to process information sent by communicating objects and send commands to said communicating objects.
Such commands sent by the server to said communicating objects concern, for example, transmission rate adjustments via a spreading factor SF ("Spread Factor") and / or TxPower transmission power level adjustments, which therefore allows ADR (Adaptive Data Rate) Adaptive Data Rate (ADR) policies to be applied. These commands can also make it possible to configure said communicating objects with respect to a frequency plan to be applied to the wireless communications of the network infrastructure.
In such LPWAN medium or long-range wireless communication systems, it is desirable to define a frequency plan, that is to say to define which frequency bands should be used by such and such equipment of said systems. , so as to limit interference during wireless communications performed within said systems. This notably makes it possible to effectively manage the mobility of terminals within said systems. Unlike cellular networks (2G, 3G, LTE), the principle of cells and transfer between cells ("handover" in English), to change cell without interruption of communications (voice, data), do not exist in the LPWAN medium or long range wireless communication systems. It is therefore desirable to provide a solution which makes it possible to define and apply effectively and automatically a frequency plan in such LPWAN medium or long-range wireless communication systems. It is also desirable to provide efficient terminal mobility in such LPWAN medium or long range wireless communication systems.
For this purpose, the invention relates to a method for defining and applying a frequency plan in an LPWAN communication system comprising a server and a plurality of gateways connected to said server, the plurality of gateways using frequencies for performing wireless communications with terminals of the communication system. The method is such that the server performs the following steps: obtaining a description of a mobility hierarchy in which mobility types are hierarchically defined; obtain a description of a mobility tree in which mobility zones are hierarchically defined, each mobility zone having a mobility type in accordance with the mobility hierarchy; obtain field measurements associated with each mobility zone defined in the mobility tree; determining, from the field measurements, for each mobility zone, a percentage of time information during which the field measurements show a received signal level RS SI less than one or more received signal level threshold RS SI among a predefined set of signal level thresholds received RSSI. In addition, the method is such that the server traverses the mobility tree by iterating the following steps: selecting the mobility zone of the highest hierarchical level not yet processed; determining, for the selected mobility zone, an average probability Pm for each frequency band, from said percentage of time information determined for each mobility zone which is a leaf of the tree and which is hierarchically connected to the zone of selected mobility; assign, for the selected mobility zone, a quantity P of frequency bands with the best average probabilities. In addition, the server performs the following steps to configure the gateways with respect to the frequency plan: obtain descriptions of mobility templates in which groupings of mobility areas are made and in which, for each grouping, a list gateways are associated with each grouping to indicate which gateways are intended to support the grouping; configure each gateway according to said template descriptions and frequency bands allocated to the mobility areas constituting said groupings. In addition, upon receipt by a terminal of a connection request to the communication system, the server obtains a description of the terminal from a terminal identifier included in said request, the description including a list of types. of mobility to which said terminal is entitled to access, and the server iterates the following steps for all types of mobility to which said terminal is entitled to access: identify the type of mobility of the highest hierarchical degree; identify which areas of mobility correspond to the type of mobility of the highest identified hierarchical level; select a mobility zone from the identified mobility zones; and assign to said terminal at least one frequency band allocated to the selected mobility zone. Finally, the method is such that the server configures said terminal according to the frequency bands thus allocated to said terminal. Thus, it is possible to define and apply efficiently, and automatically, a frequency plan in an LPWAN type of communication system, as well as to ensure efficient mobility of the terminals in such an LPWAN type communication system. .
According to a particular embodiment, the average probability Pm is calculated as follows:
where RSSId is an index value corresponding to the RSSI received minimum signal level threshold value for which a probability value has been expressed with respect to the considered mobility zone, RSSIf is a corresponding index value at the maximum value of received signal level threshold RSSI for which a probability value has been expressed with respect to the mobility zone considered, TV is the quantity of mobility zones considered for calculating the average probability Pm , and Tk (i, j) represents the probability associated with the frequency band considered for the eighth mobility zone among said N mobility areas for a received RSSI signal level threshold represented by an index value j.
According to a particular embodiment, to configure said terminal, the server performs the following steps: informing a first batch of frequency bands allocated to the terminal, via a response message to the received request; and informing a second batch of frequency bands allocated to the terminal, via one or more additional messages.
According to a particular embodiment, channels form consecutive frequency band groupings, and the server allocates the frequency bands on a channel basis.
According to a particular embodiment, the server obtains the description of the mobility hierarchy, the description of the mobility tree, the field measurements, the description of each terminal from another server external to the communication system.
According to a particular embodiment, the server verifies that the mobility type of each mobility zone of the mobility tree has a lower hierarchical degree than the mobility type of another mobility zone to which said mobility zone is directly attached in the mobility tree.
According to a particular embodiment, the description of each terminal includes information indicating whether the terminal is supposed to be fixed, and the server performs the following steps vis-à-vis the terminal having issued the received request: determine the list of the bands of frequencies eligible for said terminal; determine the frequency bands of this list that have been allocated to at least three gateways among the gateways relaying said request; and assigning the frequency bands thus determined to said EP terminal.
According to a particular embodiment, for the non-selected frequencies of said list of eligible frequency bands, the server waits to receive other frames from said terminal to determine if new gateways have relayed said other frames and thus determine if other frequency bands of said list of eligible frequency bands have been allocated to at least three gateways among the gateways having relayed said frames.
According to a particular embodiment, in the case where the amount of receiving gateways of ascending frames from said terminal remains strictly less than three, the server issues an alert. The invention also relates to a server configured to define and apply a frequency plan in an LPWAN communication system comprising, in addition to said server, a plurality of gateways connected to said server, the plurality of gateways using frequency bands to perform wireless communications with terminals of the communication system. The server is configured to: obtain a description of a mobility hierarchy in which mobility types are hierarchically defined; obtain a description of a mobility tree in which mobility zones are hierarchically defined, each mobility zone having a mobility type in accordance with the mobility hierarchy; obtain field measurements associated with each mobility zone defined in the mobility tree; determining, from the field measurements, for each mobility zone, a percentage of time information during which the field measurements show an RSSI received signal level lower than said received RSSI signal level threshold from a predefined set received signal level thresholds RSSI. In addition, the server is configured to browse the mobility tree by iterating the following steps: select the highest hierarchical mobility area not yet processed; determining, for the selected mobility zone, an average probability Pm for each frequency band, from said percentage of time information determined for each mobility zone which is a leaf of the tree and which is hierarchically connected to the zone of selected mobility; assign, for the selected mobility zone, a quantity P of frequency bands with the best average probabilities. In addition, the server is configured to perform the following steps to configure the gateways with respect to the frequency plan: obtain descriptions of mobility templates in which groupings of mobility areas are made and in which, for each grouping a list of gateways is associated with each grouping to indicate which gateways are intended to support said grouping; configure each gateway according to said template descriptions and frequency bands allocated to the mobility areas constituting said groupings. In addition, upon receipt by a terminal of a connection request to the communication system, the server is configured to obtain a description of the terminal from a terminal identifier included in said request, the description including a list of mobility types to which said terminal is entitled to access, and to iterate the following steps for all types of mobility to which said terminal is entitled to access: identify the type of mobility of the highest hierarchical degree; identify which areas of mobility correspond to the type of mobility of the highest identified hierarchical level; select a mobility zone from the identified mobility zones; and assign to said terminal at least one frequency band allocated to the selected mobility zone. Finally, the server is configured to configure said terminal according to the frequency bands thus allocated to said terminal. The invention also relates to a computer program, which can be stored on a medium and / or downloaded from a communication network, in order to be read by a processor. This computer program includes instructions for implementing the method mentioned above, when said program is executed by the processor. The invention also relates to an information storage medium storing such a computer program.
The characteristics of the invention mentioned above, as well as others, will emerge more clearly on reading the following description of an exemplary embodiment, said description being given in relation to the attached drawings, among which: Fig. 1 schematically illustrates a communication system in which the present invention can be implemented; FIG. 2 schematically illustrates an example of a hardware architecture of a communication device of the communication system of FIG. 1; FIG. 3 schematically illustrates an example of mobility hierarchy for defining a frequency plan adapted to the communication system vis-à-vis its environment; FIG. 4 schematically illustrates an example of a mobility tree in application of the mobility hierarchy of FIG. 3; FIG. 5 schematically illustrates an algorithm, implemented by a server of the communication system, of configuration of said communication system in order to apply the frequency plan adapted to the communication system vis-à-vis its environment; FIG. 6 schematically illustrates an algorithm, implemented by said server of the communication system, of creating a table of statistics of probabilities versus received signal strength level indications RSSI ("Received Signal Strength Indicator"), within the framework of the definition of the frequency plan adapted to the communication system vis-à-vis its environment; FIG. 7 schematically illustrates an algorithm, implemented by said server of the communication system, of creating a mobility table, representative of the frequency plan defined for the communication system; FIG. 8 schematically illustrates an algorithm, implemented by said communication system server, of configuration of gateways of the communication system in order to apply the defined frequency plan for the communication system; and - FIG. 9 schematically illustrates an algorithm, implemented by said communication system server, terminal configuration of the communication system to apply the defined frequency plan for the communication system. The invention is more particularly described below in a LoRaWAN (registered trademark) network infrastructure context, in particular by using terminologies that are found in the LoRaWAN (registered trademark) specifications. The principles and implementations described below, however, apply, more generally, to a LPWAN network infrastructure context.
Fig. 1 schematically illustrates a communication system in which the present invention can be implemented.
The communication system comprises a plurality of gateways GW 120, 121, 122, 123. Gateways GW 120, 121, 122, 123 have respective communication links with a server LNS 130 to which said gateways GW are attached. According to a particular embodiment, each gateway GW 120, 121, 122, 123 integrates an access function to the Internet and the communication link between said residential gateway with the LNS server 130 is based on the IP protocol ("Internet Protocol In English, as defined in the normative document RFC 791).
In the communication system, messages must be sent back to the LNS server 130 in the form of frames from each terminal device EP ("End-Point") 110, 111 of a set of terminal devices of said communication system. Said LNS server 130 has a role of control and collection of information available from the EP terminal devices 110, 111, and the gateways GW 120, 121, 122, 123 have a role of relay between the end devices EP 110, 111 and the LNS server 130. Messages, in particular control messages, can also be transmitted in the form of frames from the LNS server 130 to the EP 110, 111 terminal devices via the collection gateways GW 120, 121, 122, 123. commands sent by the LNS server 130 to the said end devices EP 110, 111 more particularly make it possible, in the context of the present invention, to configure the terminal devices EP 110, 111 with respect to a frequency plan to be applied to the wireless communications in the communication system.
In order to fulfill this relay role, each gateway GW 120, 121, 122, 123 has at least one radio interface enabling said collection gateway to communicate with at least one EP 110, 111 terminal device by relying on a wireless communication network, and preferably according to LPWAN communication technology. Said radio interface is for example of LoRa (registered trademark) type thus making it possible to implement, within the communication system, a LoRaWAN (registered trademark) data transmission protocol. Said radio interface is such that a terminal device EP can be in communication range by radio of a plurality of gateways GW, according to the geographical position of said terminal device EP with respect to the gateways GW 120, 121, 122, 123 and radio transmission conditions in the environment of said terminal device EP and gateways GW 120, 121, 122, 123. This is the case, for example, of the terminal device EP 110 in FIG. 1, which is within radio communication range of gateways GW 120, 121 and 122. EP terminal device 111 in FIG. 1 is, meanwhile, in communication range by radio gateways GW 122 and 123.
The communication system is preferably connected via the LNS server 130 to a SOE server ("Service Operator Equipment") 140, in order to allow the LNS server 130 to obtain information and descriptions from the operator. service at whose disposal the communication system was put in place. The communications between the LNS server 130 and the SOE server 140 are based on a communication protocol adapted to enable the LNS server 130 to obtain said information and said descriptions, for example the TCP (Transmission Control Protocol) protocol. , as defined in the normative document RFC 793). In an alternative embodiment, the LNS server 130 is configured to obtain said information and said descriptions via a human-machine interface implemented by said LNS server 130.
Fig. 2 schematically illustrates an example of a hardware architecture of a communication device of the communication system of FIG. Each EP terminal device 110, 111 and / or GW gateway 120, 121, 122, 123 and / or the LNS server 130 and / or the SOE server 140 may be constructed based on such a hardware architecture.
The communication device comprises, connected by a communication bus 210: a processor or CPU ("Central Processing Unit" in English) 201; Random Access Memory (RAM) 202; a ROM (Read Only Memory) 203; a storage unit or a storage medium reader, such as a SD card reader ("Secure Digital" in English) or a HDD ("Hard Disk Drive" in English) 204; an I / F communication interface 205, and possibly another I / F communication interface 206.
When the communication device of FIG. 2 shows a terminal device EP of the communication system, the I / F communication interface 205 is configured to allow said terminal device EP to communicate with one or more gateways GW of the communication system.
When the communication device of FIG. 2 represents a gateway GW of the communication system, the I / F communication interface 205 is configured to allow said gateway GW to communicate with terminal devices EP of the communication system, and the other communication interface I / F 206 is configured to allow said GW gateway to communicate with the LNS server 130.
When the communication device of FIG. 2 represents the LNS server 130, the I / F communication interface 205 is configured to enable said LNS server 130 to communicate with the GW gateways of the communication system. In a particular embodiment, the other I / F communication interface 206 is configured to enable said LNS server 130 to communicate with the SOE server 140.
When the communication device of FIG. 2 represents the SOE server 140, the I / F communication interface 205 is configured to allow said SOE server 140 to communicate with the LNS server 130.
The processor 201 is capable of executing instructions loaded into the RAM 202 from the ROM 203, an external memory, a storage medium, or a communication network. When the communication device is powered up, the processor 201 is able to read instructions from RAM 202 and execute them. These instructions form a computer program causing the processor 201 to implement all or some of the algorithms and steps described herein in relation to the communication device in question.
Thus, all or part of the algorithms and steps described here can be implemented in software form by executing a set of instructions by a programmable machine, such as a DSP ("Digital Signal Processor" in English) or a microcontroller. All or part of the algorithms and steps described here can also be implemented in hardware form by a machine or a dedicated component, such as an FPGA ("Field-Programmable Gâte Array" in English) or an ASIC ("Application-Specific Integrated Circuit"). " in English).
Fig. 3 schematically illustrates an example of mobility hierarchy for defining a frequency plan adapted to the communication system vis-à-vis its environment.
The LNS server 130 allows the service operator to define a mobility hierarchy consisting of a hierarchical set of mobility types (MobilityType). This definition of the mobility hierarchy is thus provided by the SOE server 140 to the LNS server 130, or is provided to the LNS server 130 through its man-machine interface. The hierarchical set of mobility types corresponds to the different types of geographical mobility that the EP terminals of the communication system are authorized to have: local, the size of a city, regional, national, ... or any other hierarchy of types of geographic coverage. The hierarchical set of mobility types is therefore a set of types of network coverage areas prioritized according to the size of their respective network coverage. The naming convention of mobility types and the interpretation of the hierarchy are the responsibility of the service operator.
The mobility hierarchy is therefore a hierarchical set of mobility types (MobilityType), an exemplary embodiment of which is illustrated in FIG. 3 as a tree of interconnected nodes. The root of the hierarchy is shown at the very top of FIG. 3, and represents the highest hierarchical degree. Each node of the tree has at least two elements: a mobility type name and a pointer to the parent node in the hierarchy. The root corresponds to a type of mobility generically labeled NO in FIG. 3. For example, the type of the root is named "Standard". Since the root has no parent node by definition, the pointer associated with the root is meaningless. For example, this pointer is set to a predefined value (eg "0") or points to the root itself. Two types of mobility, generically labeled Nl_l and Nl_2 in FIG. 3, are hierarchically directly attached to the root. For example, the type generically labeled Nl_l is named "Public" and the type generically labeled Nl_2 is named "Corporate". The pointers of the generically labeled mobility types Ni 1 and Nl 2 in FIG. 3 point to the root. Each of them is thus labeled PNO in FIG. 3. A single type of mobility, generically labeled N2_2 in FIG. 3, is hierarchically directly attached to the type of mobility generically labeled Nl_2 in FIG. 3. For example, the type of mobility generically labeled N2 2 in FIG. 3 is named "Postal Service". The pointer of the type of mobility generically labeled N2_2 in FIG. 3 points to the type of mobility generically labeled Nl_2 in FIG. 3, and is thus labeled PN12 in FIG. 3. A single type of mobility, generically labeled N2_1 in FIG. 3, is hierarchically directly attached to the type of mobility generically labeled Ni 1 in FIG. 3. For example, the type of mobility generically labeled N2_l in FIG. 3 is named "National". The mobility type pointer generically labeled N2_l in FIG. 3 points to the type of mobility generically labeled Ni 1 in FIG. 3, and is thus labeled PNl l in FIG. 3. A single type of mobility, generically labeled N3_l in FIG. 3, is hierarchically directly attached to the type of mobility generically labeled N2_l in FIG. 3. For example, the mobility type generically labeled N3_l in FIG. 3 is named "Agglomeration". The pointer of the type of mobility generically labeled N3_l in FIG. 3 points to the type of mobility generically labeled N2_l in FIG. 3, and is thus labeled PN21 in FIG. 3. A single type of mobility, generically labeled N4_l in FIG. 3, is hierarchically directly attached to the type of mobility generically labeled N3_l in FIG. 3. For example, the type of mobility generically labeled N4_l in FIG. 3 is named "City". The mobility type pointer generically labeled N4_l in FIG. 3 points to the type of mobility generically labeled N3_l in FIG. 3, and is thus labeled PN31 in FIG. 3. Finally, a single type of mobility, generically labeled N5_l in FIG. 3, is hierarchically directly attached to the type of mobility generically labeled N4_l in FIG. 3. For example, the type of mobility generically labeled N5_l in FIG. 3 is named "Local". The mobility type pointer generically labeled N5_l in FIG. 3 points to the type of mobility generically labeled N5_l in FIG. 3, and is thus labeled PN41 in FIG. 3.
Each node of the tree may include one or more additional elements, such as a pointer to each of its possible child nodes in the mobility hierarchy.
In the case where the LNS server 130 must manage several hierarchies, such a tree is provided to the server LNS 130 for each of said hierarchies and can thus have different structures, different naming conventions, as well as different interpretations. A hierarchy identifier is then used to distinguish, with respect to each other, the hierarchies thus defined.
Fig. 4 schematically illustrates an example of a mobility tree in application of the mobility hierarchy as previously described in relation with FIG. 3.
A mobility tree is an instance of a mobility hierarchy. This tree corresponds to a geographical coverage description of the communication system's wireless communications for a given service, in which each node of the tree is an instance of a mobility type defined in said mobility hierarchy and in which each node of the tree is associated with a mobility zone (MobilityArea). Each mobility zone is associated with a mobility type (MobilityType) with a hierarchical degree lower than that associated with its parent node, or parent mobility zone. Each node of the tree has at least four elements: a mobility zone name MA, the mobility type of said mobility zone, a PTR pointer to the parent mobility zone, and at least one frequency band F associated with said mobility zone. The frequency band or bands F associated with said mobility zone are determined as described below in relation to FIGS. 6-8.
An example of a mobility tree is shown in FIG. 4, based on the example of the mobility hierarchy shown in FIG. 3. The mobility tree then has a root 401 which is a mobility type instance "Standard". For example, the root 401 represents a mobility zone MA called "LoRa". The mobility tree also has two nodes 411 and 441 directly attached to the root 401. The node 411 is a public mobility type instance, and the node 441 is a "Corporate" mobility type instance. For example, the node 411 represents a mobility zone MA called "Public", and the node 441 represents a mobility zone MA called "Corporate". The mobility tree also has two nodes 421 and 431 directly attached to the node 411. The nodes 421 and 431 are instances of mobility type "National". For example, the node 421 represents a mobility zone MA called "Tunisia", and the node 431 represents a mobility zone MA called "France". A single node 422 is directly attached to node 421. Node 422 is an instance of mobility type "City". For example, the node 422 represents a mobility zone MA called "Tunis". It will therefore be noted that each mobility zone is associated with a mobility type (MobilityType) with a hierarchical degree lower than that associated with its parent mobility zone in the mobility tree, without it being necessary that said mobility zone is associated with a mobility type (MobilityType) with a hierarchical degree immediately below that associated with its parent mobility zone in the mobility hierarchy considered. In other words, hierarchical degree jumps can be made to define the mobility tree, relative to the definition of the mobility hierarchy of which the mobility tree is an instance. A single node 432 is directly attached to node 431. Node 432 is an instance of mobility type "Agglomeration". For example, the node 432 represents a mobility zone MA called "Agglomeration Parisienne". A single node 433 is directly attached to node 432. Node 433 is an instance of mobility type "City". For example, the node 433 represents a mobility zone MA called "Rueil". A single node 434 is directly attached to node 433. Node 434 is a "local" mobility type instance. For example, the node 434 represents a mobility zone MA called "Sagemcom". Finally, a single node 442 is directly attached to the node 441. The node 442 is a mobility type instance "Postal Service". For example, the node 442 represents a mobility zone MA called "Garages Automobiles".
Each node of the tree may comprise one or more additional elements SI, such as for example a pointer to each of its possible child nodes.
In the case where the LNS server 130 must manage several hierarchies, such a tree is provided to the LNS server 130 in association with a hierarchy identifier assigned to the mobility hierarchy to which said mobility tree refers. Several mobility trees can be defined as separate instances of the same mobility hierarchy. A mobility tree identifier is then used to distinguish, with respect to each other, the mobility trees thus defined.
Fig. 5 schematically illustrates an algorithm, implemented by the LNS server 130, configuration of the communication system to apply a frequency plan adapted to the communication system vis-à-vis its environment.
In a step 501, the LNS server 130 obtains a description of mobility hierarchy, as presented above in relation to FIG. 3.
In a step 502, the LNS server 130 obtains a description of a mobility tree as presented above in relation to FIG. 4. Preferentially, the LNS server 130 verifies the conformity of the mobility tree with respect to the mobility hierarchy.
In a step 503, the LNS server 130 obtains field measurements associated with each mobility zone defined in the mobility tree. This aspect is detailed below with reference to FIG. 6.
In a step 504, the LNS server 130 establishes a frequency plan to be applied within the communication system, from the field measurements and from the mobility tree, in order to improve the communications performance of the communication system. to his environment. This aspect is detailed below with reference to FIG. 7.
In a step 505, the LNS server 130 instructs the gateways GW and the terminals EP of the communication system to apply the frequency plan defined in step 504. This aspect is detailed below in relation to FIGS. 8 and 9.
Fig. 6 schematically illustrates an algorithm, implemented by the LNS server 130, of creating an array of probability statistics versus RSSI received signal level indications, in the context of the definition of the frequency plan adapted to the communication system vis- with respect to its environment.
In a step 601, the LNS server 130 obtains field measurements, for each mobility area (MobilityArea) which is a leaf (end point of the tree relative to the root of the tree) in the tree. mobility obtained by the LNS server 130 in step 501. The field measurements are provided to the LNS server 130 by the SOE server 140 or by input via its human-machine interface.
The LNS server 130 manipulates the obtained field measurements, so as to obtain, per frequency band or channel usable for wireless communications between the GW gateways and the EP terminals, information of percentage of time during which the measurements of field show a received signal level lower than any received RSSI signal level threshold from a predefined set of RSSI received signal level thresholds. This aspect is detailed below with reference to the rest of the algorithm of FIG. 6.
Field measurements are acquired as follows. The objective is to know, with the best possible accuracy, the noise present in the different frequency bands in which the communication system is authorized to make communications, in order to be able to determine a frequency plan adapted to the communication system vis- with respect to its environment.
The principle of the measurement consists, for each mobility area concerned, of connecting a radio receiver of the spectrum analyzer type to an antenna of a high point of said mobility zone and recording over time noise samples in the different frequency bands. For example, the communication system is allowed to perform communications in 25 kHz frequency bands between 863 MHz and 870 MHz. The radio receiver records variations of the RSSI received level for a predefined duration per frequency band, and thus proceeds successively for all the frequency bands in which the communication system is authorized to carry out communications. This procedure can be iterated over several cycles, the acquired measurements then being combined according to a predefined rule (addition, average, max, min, ...) to those previously acquired. The greater the number of cycles performed, the greater the precision on the noise statistically present in the frequency bands under consideration. The measurements can then be grouped by communication channel, if such communication channels comprising several consecutive frequency bands are defined to carry out the wireless communications of the communication system. For example, the measurements made are grouped together per 125 kHz wide communication channel, each grouping five consecutive 25 kHz frequency bands. This grouping can also be performed by the LNS server 130, as described below in connection with a step 602.
Thus, the measurements made can be presented in the form of a table of measurements having, on the ordinate, the frequency bands or channels considered and on the abscissa of the predefined values (thresholds) of received level RSSI. Each cell of the array then comprises, for the frequency band or channel corresponding to said cell, a time information during which the measurements carried out show an RSSI received signal level less than or equal to the corresponding RSSI received level preset value (threshold). to said cell. Each line of the table is associated with time information T during which the measurements have been made for the frequency band or the channel corresponding to said line.
In step 602, to carry out, if necessary, groupings of measurements per channel from measurements obtained by frequency band (each channel being a predefined grouping of several consecutive frequency bands), the LNS server 130 adds between them the values contained therein. in the relevant cells of the field measurement table. Each channel is then associated with the sum of the time information T which was previously associated with the frequency bands constituting said channel. From the measurements made, it is possible to determine, by frequency band or channel, the percentage of the time during which there is statistically no noise greater than a given value (threshold) of received signal RSSI. For this, in a step 603, the LNS server 130 determines, for each frequency band or channel in question, the time of the field measurements which gave an RSSI received signal level lower than the received signal threshold value (threshold). RSSI considered, and this, vis-à-vis each preset value (threshold) signal received RSSI. The LNS server 130 then divides this time by the quantity of time units during which the measurements have been carried out for the frequency band or the channel in question, which gives, by threshold value RSSI, the percentage of time sought.
In a step 604, the LNS server 130 creates, or updates, a table of statistics of probabilities versus received signal level RSSI. This statistics table then contains on the ordinate the frequency bands or channels considered and on the abscissa the predefined values (thresholds) of level received RSSI. Each cell of the array then comprises, for the frequency band or channel corresponding to said cell, the percentage of time information during which the field measurements have given an RSSI received signal level less than or equal to the predefined value (threshold). RSSI received signal level corresponding to said cell. The statistics table thus created is then used by the LNS server 130, as detailed below in connection with FIG. 7. In an alternative embodiment, the LNS server 130 receives from the SOE server 140, or via its man-machine interface, directly the table of statistics of probabilities versus received signal level RSSI.
Fig. 7 schematically illustrates an algorithm, implemented by the LNS server 130, for creating a mobility table representative of the frequency plan defined for the communication system.
In a step 701, the LNS server 130 selects the mobility zone of the highest hierarchical degree not yet processed in the context of the current execution of the algorithm of FIG. 7. When there are several mobility zones of the same hierarchical degree that can be selected by the LNS server 130 in the step 701, the LNS server 130 applies a predefined rule to select a mobility zone among the mobility zones of the same degree. hierarchy that can be selected by the LNS server 130 in step 701. At the first sequence iteration of step 701 as part of the current execution of the algorithm of FIG. 7, the LNS server 130 selects the root mobility area of the mobility tree.
In a step 702, the LNS server 130 determines, for the mobility zone selected in step 701, an average probability Pm for each frequency band or channel, from the statistics table (of probabilities versus received signal level RSSI ) obtained with respect to each mobility zone which happens to be a leaf of the mobility tree and which is hierarchically (indirectly or directly) attached to the mobility zone selected in step 701. This average probability Pm is representative of the probability that there is no noise leading to a given RSSI value on the frequency band or channel in question.
The average probability Pm above is calculated as follows:
where RSSld is an index value corresponding to the minimum threshold value RSSI for which a probability value has been expressed in the probability table considered, RSSIf is an index value corresponding to the maximum value of RSSI threshold for which a probability value has been expressed in the probability table considered, N is the quantity of tables of probability statistics considered for the calculation of the average probability
represents the probability associated with the considered frequency band or the channel considered in the k-th probability table (among the considered tables) for an RSSI threshold represented by an index value j.
In a step 703, the LNS server 130 selects up to a predefined quantity P (P> 1) of frequency bands or channels among the frequency bands or channels usable by the communication system for carrying out the wireless communications. The frequency bands or channels selected by the LNS server 130 are the frequency bands or channels with the best average probabilities (highest values) as calculated in step 702, provided that the frequency bands or channels in question have not already been assigned to the root or a mobility area which is an intermediate in the mobility tree between the root and the mobility area selected in step 701. If less than P frequency bands or channels remain after removing the frequency bands or channels allocated to the root or a mobility area that is an intermediate in the mobility tree between the root and the mobility area selected in step 701, then the LNS server 130 select those frequency bands or channels that remain. If all the frequencies have been selected and there are still areas of mobility to be treated, then the LNS server 130 does not allocate itself frequencies to these mobility zones. This is a case of poor sizing of the communication system by the service operator. Therefore, the LNS server 130 sends an alarm to the SOE server 140 so that the service operator can set back a frequency allocation policy accordingly, such as forcing the assignment of the P frequency bands or channels having the best average probabilities or cancel the implementation, in progress, of the frequency plan. If at least P frequency bands or channels remain after removing the frequency bands or channels assigned to the root or mobility area that is an intermediate in the mobility tree between the root and the selected mobility area at the same time. In step 701, the LNS server 130 selects the P frequency bands or channels having the best average probabilities as calculated in step 702. The frequency bands or channels thus selected by the LNS server 130 are then allocated to the selected mobility in step 701.
The quantity P may be a default setting of the LNS server 130; the quantity P may alternatively be a parameter provided by the SOE server 140 to the LNS server 130. Note that the parameter P is potentially different from one mobility zone to another.
In a step 704, the LNS server 130 checks whether at least one other mobility zone of the mobility tree is to be considered. The LNS server 130 is expected to traverse the tree from the root of the tree to each leaf of the tree, until the tree is fully traversed. If at least one minus another mobility zone is to be considered, step 701 is repeated; otherwise, a step 705 is performed.
In step 705, the LNS server 130 creates, or updates, a mobility table associated with the mobility tree in question. The mobility table provides, for each mobility zone of the mobility tree, one or more frequency bands or channels which have thus been allocated to said mobility zone. The mobility table may contain additional information, such as a reminder of the type of mobility characterizing the mobility zone in question, a reminder of the parent mobility zone in the mobility tree, etc.
Fig. 8 schematically illustrates an algorithm, implemented by the LNS server 130, GW gateways configuration to apply the frequency plan as defined by execution of the algorithm of FIG. 7.
In a step 801, the LNS server 130 obtains descriptions of mobility templates that respectively correspond to sets of mobility areas. Indeed, in order to cover as many possible mobility zones, each GW gateway preferably supports several mobility zones, which results in the fact of managing frequency bands or channels allocated to several mobility zones. To achieve this, the LNS server 130 obtains these mobility templates from the SOE server 140 or by input via its human-machine interface.
For consistency in radio coverage, all frequency bands (or channels) or portions of these frequency bands (or channels) assigned to each mobility zone must be configured in all GW gateways which the mobility zone corresponds to. Indeed, the EP terminals supposed to be active in the same mobility zone must be configured to communicate via frequency bands or channels allocated to this mobility zone. If an EP terminal is configured with a frequency band or a channel which is not configured in a surrounding GW gateway capable of receiving the "uplink frames" transmitted by said terminal, then these upstream frames are not not received by this GW gateway. Consequently, an incorrect configuration vis-à-vis the frequency plan unnecessarily increases the rate of frame loss ("Frame Error Rate" in English).
It is furthermore possible to split the frequency plan of a gateway GW into several hierarchies. For example, a quantity of channels could be assigned to a first mobility hierarchy and a quantity of other channels could be assigned to a second mobility hierarchy. It should be kept in mind that a bad configuration could lead to duplicate frequency bands, which would disrupt the establishment of these hierarchies in parallel.
Each template document comprises the following information: a template identifier, a list of the mobility zones contained in the radio coverage area associated with the template, and a list of GW gateways that must make it possible to carry out said radio coverage area. When the communication system supports multiple mobility hierarchies in parallel, each template further comprises an identifier of the mobility hierarchy to which said template refers.
In a step 802, the LNS server 130 determines, from the mobility table obtained by executing the algorithm of FIG. 7 and template descriptions obtained in step 801, the list of frequency bands or channels assigned to each template. This list corresponds to the aggregation of the frequency bands or channels allocated to the mobility zones constituting the jig in question. The LNS server 130 can update the template descriptions with the list of frequency bands respectively allocated to said templates.
In a step 803, the LNS server 130 creates a frequency allocation table GWT-F for each gateway GW, from the template descriptions. Each template document lists the GW gateways that are affected by the template in question, and the lists of frequency bands or channels assigned to each template then enable the LNS server 130 to define which frequency bands or channels should be supported by each gateway. GW. Each frequency allocation table GWT-F then indicates a list of the frequency bands or channels in association with a template identifier from which said list of frequency bands or channels originates, and for each template concerned by the GW gateway. referred to by said frequency allocation table GWT-F. When the communication system supports multiple mobility hierarchies in parallel, each frequency allocation table GWT-F may further include the identifier of the mobility hierarchy to which each template refers.
In a step 803, the LNS server 130 configures each gateway GW so that said gateway GW uses, for radio communication with terminals EP, the frequency bands or channels that have been allocated to it according to the frequency allocation table. GWT-F associated with said gateway GW. Step 803 is for example performed by sending a message from the LNS server 130 to each of the GW gateways, using a JSON ("JavaScript Object Notation") format. Each GW gateway is configured accordingly.
Fig. 9 schematically illustrates an algorithm, implemented by LNS server 130, for configuring EP terminals to apply the frequency plan as defined by executing the algorithm of FIG. 7.
In a step 901, the LNS server 130 receives a JoinReq request for connection to the communication system from an EP terminal. This JoionReq request is relayed to the LNS server 130 by at least one GW gateway having received it directly from the terminal EP. To send this JoinReq request, the terminal EP uses a frequency band which is necessarily supported by any EP terminal and by any GW gateway when this EP terminal or this GW gateway is intended to be used within the communication system. For example, according to LoRaWAN technology, any EP terminal and GW gateway must support three default frequency bands. The allocation of frequency bands or channels to which reference is made in Figs. 6 to 8 relates to the frequency bands or channels other than those supported by default by any EP terminal and any GW gateway.
In a step 902, the LNS server 130 obtains a description of the terminal EP from which the LNS server 130 received the JoinReq request in step 901. The JoinReq request received in step 901 contains an identifier of the terminal EP. In a first embodiment, the SOE server 140 has previously provided the LNS server 130 with a description of each EP terminal capable of connecting to the communication system. In a second embodiment, the LNS server 130 obtains the identifier of the terminal EP from the JoinReq request received in step 901, and sends to the SOE server 140 a message containing said identifier in order to receive in response the description of the EP terminal in question. The description of each EP terminal contains a list of mobility types (MobilityType) and a quantity of frequency bands or channels to be assigned to the EP terminal in question by type of mobility listed. The description can be supplemented with additional information, such as for example a quantity of repeats NbRep that the terminal EP is supposed to perform for each frame transmission, a maximum upward flow, a minimum upward flow, ... When the communication system supports several mobility hierarchies in parallel, the description further contains the identifier of each mobility hierarchy vis-à-vis which said EP terminal must be configured. The description of the terminal EP as provided by the server SOE 140 depends for example on a subscription actually subscribed by a user of said terminal EP to the service operator.
In a step 903, the LNS server 130 identifies, from the description of the terminal EP obtained in step 902 (with the list of mobility types), which is the type of mobility of the highest hierarchical degree to which said terminal EP has the right of access. When there are several types of mobility of the same hierarchical degree that can be identified by the LNS server 130 in the step 903, the LNS server 130 applies a predefined rule to select a type of mobility among those of the same hierarchical degree that can be identified by the LNS server 130 in step 903.
In a step 904, the LNS server 130 identifies, from the mobility type identified in step 902 and from the mobility tree (mobility type instances), which are the higher degree mobility zones. hierarchical to which said EP terminal is entitled to access.
In a step 905, the LNS server 130 checks whether at least one mobility zone has been identified in step 904. If so, a step 906 is performed; otherwise, a step 909 is performed.
In step 906, the LNS server 130 selects a mobility zone from the zones identified in step 904. Thus, when there are several mobility zones of the same hierarchical degree that can be identified by the LNS server 130 in the At step 904, the LNS server 130 applies a predefined rule to select a mobility area from those of the same hierarchical degree identified by the LNS server 130 in step 904. For example, the LNS server 130 selects the mobility area that is included in a template that has the largest amount of GW gateways listed. According to another approach, the LNS server 130 selects the mobility zone supported by the largest amount of GW gateways. The LNS server 130 may then request it from the SOE server 140 by providing it with a list of the zones identified in step 904. According to yet another approach, the LNS server 130 obtains from each GW gateway that has received and relayed the request referred to in step 901, received RSSI received signal level information upon receipt of said request by said GW gateway. The LNS server 130 then determines an average of the RSSI received signal levels measured upon receipt of said request by the GW gateways of each mobility area concerned, and the LNS server 130 selects the mobility zone having the highest average level. received signal RSSI measured upon receipt of said request.
In a step 907, the LNS server 130 selects, according to a predefined rule, at least one frequency band or at least one channel allocated to the mobility zone selected in step 906, thanks to the mobility table. For example, the LNS server 130 randomly selects at least one frequency band or at least one channel allocated to the mobility zone selected in step 906. Each EP terminal can only support a predefined maximum amount of frequency bands or of channels, the LNS server 130 thus selects a quantity of frequency bands or channels in step 907, so that, in total, a quantity of frequency bands or channels selected for the terminal EP remains less than or equal to the predefined maximum quantity of frequency bands or channels that the EP terminal can support. For example, this predefined maximum quantity of frequency bands or channels that can support the EP terminal is set to thirteen.
In a step 908, the LNS server 130 checks whether the preset maximum amount of frequency bands or channels that can support the terminal EP is reached. If this is the case, a step 911 is performed; otherwise, step 909 is performed.
In step 909, the LNS server 130 checks whether at least one type of mobility area remains to be processed. If this is the case, a step 910 is performed; otherwise, step 911 is performed.
In step 910, the LNS server 130 identifies which type of mobility of the highest hierarchical degree to which said terminal EP is entitled to access, excluding each type of mobility previously treated in the context of the execution of the algorithm of FIG. 9 (previous iterations of steps 903 and 910 as part of the current execution of the algorithm of Fig. 9). Next, step 904 is repeated.
In step 911, the LNS server 130 configures the terminal EP so that said terminal EP uses, for radio communication within the communication system, the frequency bands or channels that have been selected during the previous iterations of step 907 (as part of the current execution of the algorithm of Fig. 9).
In a particular embodiment, in accordance with the message formats used in the LoRaWAN technology, the LNS server 130 configures the terminal EP in the following manner. The LNS server 130 informs the EP terminal of a first batch of frequency bands or channels to be used, in a JoinAccept message in response to the JoinReq request received in step 901. The LNS server 130 uses a GW gateway as a relay of the JoinAccept message. Preferably, according to the message formats used in the LoRaWAN technology, up to five frequency bands or channels are thus indicated in the JoinAccept message. The LNS server 130 then informs the EP terminal of a second batch of frequency bands or channels to be used, in one or more NewChannelReq complementary messages. Preferably, according to the message formats used in the LoRaWAN technology, a single frequency band or a single channel is thus indicated in each additional NewChannelReq message. The LNS server 130 proceeds thus until said terminal EP is informed of all the frequency bands or channels which have been selected for said terminal EP during the previous iterations of the step 907 (within the framework of the current execution of the algorithm in Fig. 9). The terminal EP is configured accordingly.
In another particular embodiment, the description of the terminal EP obtained in step 902 includes information, provided by the server SOE 140, indicating whether the terminal EP is supposed to be fixed (eg the terminal EP is a fixed sensor in a home automation service). In order to make it possible to actually locate a fixed EP terminal, the LNS server 130 must configure said EP terminal with frequency bands or channels supported by at least three gateways GW capable of receiving the upstream frames transmitted by said EP terminal. As explained above, the LNS server 130 determines the list of frequency bands or channels eligible for said EP terminal. Based on the GW gateways that relayed the JoinReq request to allow the LNS server 130 to receive said JoinReq request in step 901, the LNS server 130 determines the frequency bands or channels of that list that have been assigned to at least three. GW gateways among GW gateways relaying said JoinReq request. The LNS server 130 assigns these frequency bands or channels to said EP terminal. For non-selected frequencies, the LNS server 130 preferably waits to receive more ascending frames from said EP terminal to determine if new GW gateways have received, and thus relayed, said upstream frames. The LNS server 130 determines whether other frequency bands or channels of the list of frequency bands or channels eligible for said EP terminal have been allocated to at least three gateways GW among GW gateways having relayed said ascending frames. In the case where the amount of GW gateways receiving upstream frames from said EP terminal is always strictly less than three, the actual location of said EP terminal is not possible. The allocation of frequency bands or channels to said EP terminal is then performed, as previously described, without taking into account the need for localization of the EP terminal. The LNS server 130 then sends an alert to the SOE server 140 in order to inform said SOE server 140, and therefore the service operator, that the location is not possible for said EP terminal.

权利要求:
Claims (12)
[1" id="c-fr-0001]
1) A method of defining and applying a frequency plan in an LPWAN type communication system comprising a server (130) and a plurality of gateways (120, 121, 122, 123) connected to said server, the plurality gateways using frequency bands for carrying out wireless communications with terminals (110, 111) of the communication system, characterized in that the server performs the following steps: obtaining (501) a description of a mobility hierarchy in which mobility types are hierarchically defined; obtaining (502) a description of a mobility tree in which mobility areas are hierarchically defined, each mobility area having a mobility type in accordance with the mobility hierarchy; obtain (503, 601) field measurements associated with each mobility zone defined in the mobility tree; determining (603), from the field measurements, for each mobility area, a percentage of time information during which the field measurements show an RSSI received signal level lower than any received RSSI signal level threshold among a predefined set of RSSI received signal level thresholds; in that the server traverses the mobility tree by iterating the following steps: selecting (701) the mobility zone of the highest hierarchical degree not yet processed; determining (702), for the selected mobility area, an average probability Pm for each frequency band, from said time percentage information determined for each mobility zone which is a leaf of the tree and which is hierarchically related to the selected mobility zone; assigning (705), for the selected mobility zone, up to a quantity P of frequency bands having the best average probabilities; in that the server performs the following steps to configure the gateways with respect to the frequency plan: obtaining (801) descriptions of mobility templates in which groupings of mobility areas are made and in which, for each grouping a list of gateways is associated with each grouping to indicate which gateways are intended to support said grouping; configuring (804) each gateway according to said template descriptions and frequency bands allocated to the mobility areas constituting said groupings; in that, on receiving (901) from a terminal of a connection request to the communication system, the server obtains (902) a description of the terminal from a terminal identifier included in said request, the description including a list of mobility types to which said terminal is entitled to access, and the server iterates the following steps for all types of mobility to which said terminal is entitled to access: identify (903, 910) the type mobility of higher hierarchical degree; identify (904) which mobility areas correspond to the identified higher mobility type of mobility; selecting (906) a mobility zone from the identified mobility zones; allocating (907) said terminal at least one frequency band allocated to the selected mobility zone; and in that the server configures (911) said terminal according to the frequency bands thus allocated to said terminal.
[0002]
2) Method according to claim 1, characterized in that the average probability Pm is calculated as follows:

where RSSId is an index value corresponding to the RSSI received minimum signal level threshold value for which a probability value has been expressed with respect to the considered mobility zone, RSSIf is a corresponding index value at the maximum value of received signal level threshold RSSI for which a probability value has been expressed with respect to the mobility zone considered, N is the quantity of mobility zones considered for calculating the average probability Pm , and Tk (i, j) represents the probability associated with the frequency band considered for the Æ-th mobility zone among said N mobility areas for a received RSSI signal level threshold represented by an index value j.
[0003]
3) Method according to any one of claims 1 and 2, characterized in that, to configure said terminal, the server performs the following steps: inform a first batch of frequency bands allocated to the terminal, via a response message the request received; and informing a second batch of frequency bands allocated to the terminal, via one or more additional messages.
[0004]
4) Method according to any one of claims 1 to 3, characterized in that channels form groups of consecutive frequency bands, and the server allocates the frequency bands on a channel basis.
[0005]
5) Method according to any one of claims 1 to 4, characterized in that the server obtains the description of the mobility hierarchy, the description of the mobility tree, the field measurements, the description of each terminal from another server (140) external to the communication system.
[0006]
6) Method according to claim 5, characterized in that the server verifies that the mobility type of each mobility zone of the mobility tree has a lower hierarchical degree than the mobility type of another mobility zone to which said mobility area is directly attached in the mobility tree.
[0007]
7) Method according to any one of claims 1 to 6, characterized in that the description of each terminal includes information indicating whether the terminal is supposed to be fixed, and the server performs the following steps vis-à-vis the terminal having issued the received request: determine the list of the frequency bands eligible for said terminal; determine the frequency bands of this list that have been allocated to at least three gateways among the gateways relaying said request; and assigning the frequency bands thus determined to said EP terminal.
[0008]
8) Method according to claim 7, characterized in that, for the unselected frequencies of said list of eligible frequency bands, the server waits to receive other frames from said terminal to determine if new gateways have relayed said other frames and thus determine if other frequency bands of said list of eligible frequency bands have been allocated to at least three gateways among the gateways having relayed said other frames.
[0009]
9) Method according to claim 8, characterized in that, in the case where the amount of receiving gateways of ascending frames from said terminal remains strictly less than three, the server issues an alert.
[0010]
A computer program comprising a set of instructions causing a processor (201) to execute a server (130) to be included in a LPWAN long-range wide area network, the method according to any one of claims 1 to 9, when said computer program is executed by said processor.
[0011]
An information storage medium storing a computer program comprising a set of instructions causing a processor (201) to execute a server (130) to be included in a long-range wide area network. LPWAN type, the method according to any one of claims 1 to 9, when said computer program is executed by said processor.
[0012]
A server (130) configured to define and apply a frequency plan in an LPWAN communication system comprising, in addition to said server, a plurality of gateways (120, 121, 122, 123) connected to said server, the plurality of gateways using frequency bands for performing wireless communications with terminals (110, 111) of the communication system, characterized in that the server is configured to: obtain (501) a description of a mobility hierarchy in which types of mobility are hierarchically defined; obtaining (502) a description of a mobility tree in which mobility areas are hierarchically defined, each mobility area having a mobility type in accordance with the mobility hierarchy; obtain (503, 601) field measurements associated with each mobility zone defined in the mobility tree; determining (603), from the field measurements, for each mobility zone, a percentage of time information during which the field measurements show a received signal level RS SI less than this or that received signal level threshold RSSI among a predefined set of received signal level thresholds RS SI; in that the server is configured to traverse the mobility tree by iterating the following steps: selecting (701) the highest non-processed hierarchical mobility zone; determining (702), for the selected mobility area, an average probability Pm for each frequency band, from said time percentage information determined for each mobility zone which is a leaf of the tree and which is hierarchically related to the selected mobility zone; assigning (705), for the selected mobility zone, up to a quantity P of frequency bands having the best average probabilities; in that the server is configured to perform the following steps to configure the gateways with respect to the frequency plan: obtaining (801) mobility template descriptions in which groupings of mobility areas are made and in which, for each grouping, a list of gateways is associated with each grouping to indicate which gateways are intended to support said grouping; configuring (804) each gateway according to said template descriptions and frequency bands allocated to the mobility areas constituting said groupings; in that, upon receiving (901) from a terminal of a connection request to the communication system, the server is configured to obtain (902) a description of the terminal from a terminal identifier included in said request, the description including a list of mobility types to which said terminal is entitled, and to iterate the following steps for all types of mobility to which said terminal is entitled to access: identifier (903, 910) the type of mobility of the highest hierarchical degree; identify (904) which mobility areas correspond to the identified higher mobility type of mobility; selecting (906) a mobility zone from the identified mobility zones; allocating (907) said terminal at least one frequency band allocated to the selected mobility zone; and in that the server is configured to configure (911) said terminal according to the frequency bands thus allocated to said terminal.

类似技术:

---

公开号 | 公开日 | 专利标题

---

EP3258736B1|2020-07-29|Method for defining and applying a frequency plan

---

EP3381222B1|2020-01-08|Gateway configuration method

---

FR3012895A1|2015-05-08|METHOD AND COMPUTER PROGRAM FOR PERFORMING COMPUTER TASKS OF WIRELESS EQUIPMENT

---

WO2017144406A1|2017-08-31|Method for the dynamic adaptation of a data rate

---

EP3395045B1|2021-06-09|Method for determining a temporal reference and/or at least one spatial reference in a communication system

---

EP3675435A1|2020-07-01|Method for dynamic routing in a network of connected objects

---

EP3777308B1|2021-07-07|Communication method

---

CA2776333C|2019-04-23|Method for optimizing the quality of a cellular network

---

EP3672209B1|2021-09-15|Method for identifying a communication node

---

EP3934111A1|2022-01-05|Method for selecting a communication route

---

EP1681833A1|2006-07-19|Systems and methods for providing access to a location specific service in a wireless telecommunications network

---

EP3817294A1|2021-05-05|Method and module for a connectivity regulation of connected objects.

---

EP3160188B1|2019-12-04|Communication method with computation of a path from elementary networks, related computer program, interconnection node and radio station

---

WO2020225075A1|2020-11-12|Method for selecting gateways

---

WO2021116572A1|2021-06-17|Method and device carrying out said method for accessing a shared channel in order to respond to a relay request

---

CA3077313A1|2019-04-04|Method of aiding toggling of a mobile terminal between community wireless local area networks

---

FR3087610A1|2020-04-24|EXCHANGE OF DATA IN AN INFRASTRUCTURE OF CONNECTED OBJECTS

---

FR3095914A1|2020-11-13|Method of dynamic routing in a network of connected objects

---

EP3811655A1|2021-04-28|Method for evaluating the energy consumption of a service unit in a communications network

---

WO2020002376A1|2020-01-02|Method for managing a connection in a distributed wireless network

---

WO2019106259A1|2019-06-06|Configuration method intended to be implemented in a network useing a dynamic routing protocol

---

FR3081278A1|2019-11-22|DISTRIBUTED METHOD OF ALLOCATING TRANSMISSION RESOURCES TO D2D TERMINALS IN A CELLULAR ACCESS NETWORK.

---

FR3068811A1|2019-01-11|RELIABILITY OF NETWORK MAPPING

---

FR2939271A1|2010-06-04|Communication routing management method for home theatre type communication network, involves adapting routing of communication in wireless communication network based on estimated capacity level

同族专利:

---

公开号 | 公开日

---

EP3258736A1|2017-12-20|

---

US10277234B2|2019-04-30|

---

US20170366194A1|2017-12-21|

---

EP3258736B1|2020-07-29|

---

FR3052952B1|2018-07-13|

引用文献:

---

公开号 | 申请日 | 公开日 | 申请人 | 专利标题

---

---

WO1998010307A1|1996-09-09|1998-03-12|Dennis Jay Dupray|Location of a mobile station|

---

US7903029B2|1996-09-09|2011-03-08|Tracbeam Llc|Wireless location routing applications and architecture therefor|

---

US6405043B1|1997-07-02|2002-06-11|Scoreboard, Inc.|Method to characterize the prospective or actual level of interference at a point, in a sector, and throughout a cellular system|

---

US6493331B1|2000-03-30|2002-12-10|Qualcomm Incorporated|Method and apparatus for controlling transmissions of a communications systems|

---

US8320948B2|2009-03-25|2012-11-27|Futurewei Technologies, Inc.|System and method for probability-based resource allocation in a wireless communications system|

---

US9585024B2|2010-07-27|2017-02-28|Huawei Technologies Co., Ltd.|System and method for self-organized inter-cell interference coordination|

---

US9516507B2|2010-08-12|2016-12-06|Samsung Electronics Co., Ltd.|Apparatus and methods of enhancers for low power nodes in wireless communication|

---

CN102469491B|2010-11-05|2016-08-10|北京三星通信技术研究有限公司|A kind of radio resource measurement method under heterogeneous network scene|

---

US8750876B2|2012-02-15|2014-06-10|Telefonaktiebolaget L M Ericsson |Methods and devices for adjusting resource management procedures in heterogeneous communication networks based on cell information|US10567495B2|2016-11-16|2020-02-18|Cisco Technology, Inc.|Application based intelligent edge computing in a low power wide area network environment|

---

US10383060B2|2017-08-29|2019-08-13|Comcast Cable Communications, Llc|Systems and methods for using a mobile gateway in a low power wide area network|

---

CN108449763B|2018-03-15|2021-03-16|重庆邮电大学|LoRaWAN network rate self-adaptive adjusting method based on channel state identification|

---

CN110557184B|2018-05-31|2021-11-16|阿里巴巴集团控股有限公司|Communication method and device based on relay equipment and communication method and device between terminal and base station|

---

CN109257829B|2018-09-05|2021-08-24|深圳市艾森智能技术有限公司|Synchronous service implementing method for LPWA network|

---

CN110505633A|2019-01-31|2019-11-26|物兴科技有限公司|A kind of means of communication, communication device and the communication system of energy information acquisition|

---

KR20200114554A|2019-03-29|2020-10-07|한국전자통신연구원|Method for relaying message in low power wide area network and apparatus for the same|

法律状态:
2017-05-22| PLFP| Fee payment|Year of fee payment: 2 |

---

2017-12-22| PLSC| Search report ready|Effective date: 20171222 |

---

2018-05-25| PLFP| Fee payment|Year of fee payment: 3 |

---

2020-05-20| PLFP| Fee payment|Year of fee payment: 5 |

---

2021-05-19| PLFP| Fee payment|Year of fee payment: 6 |

优先权:

---

申请号 | 申请日 | 专利标题

---

FR1655553|2016-06-15|

---

FR1655553A|FR3052952B1|2016-06-15|2016-06-15|METHOD FOR DEFINING AND APPLYING A FREQUENCY PLAN|FR1655553A| FR3052952B1|2016-06-15|2016-06-15|METHOD FOR DEFINING AND APPLYING A FREQUENCY PLAN|

---

US15/602,814| US10277234B2|2016-06-15|2017-05-23|Method for defining and applying a frequency plan|

---

EP17175414.6A| EP3258736B1|2016-06-15|2017-06-12|Method for defining and applying a frequency plan|